Hi Eric,
Currently, unless caller has CAP_SETGID in parent namespace, we can
only map effective group id in the new user namespace. Would it be
possible to relax this rule to also allow mapping of supplemental
groups (1:1) of the caller?
Thanks.
--
Dmitry
On Thu, Feb 28, 2019 at 11:27:38AM -0800, Dmitry Torokhov wrote:
> Hi Eric,
>
> Currently, unless caller has CAP_SETGID in parent namespace, we can
> only map effective group id in the new user namespace. Would it be
> possible to relax this rule to also allow mapping of supplemental
> groups (1:1) of the caller?
>
> Thanks.
>
> --
> Dmitry
Hi,
Is there a use case where adding those to /etc/subgid is onerous?
(There probably is, just would like to see yours)
thanks,
-serge
Hi Serge,
On Thu, Mar 28, 2019 at 11:05 AM Serge E. Hallyn <[email protected]> wrote:
>
> On Thu, Feb 28, 2019 at 11:27:38AM -0800, Dmitry Torokhov wrote:
> > Hi Eric,
> >
> > Currently, unless caller has CAP_SETGID in parent namespace, we can
> > only map effective group id in the new user namespace. Would it be
> > possible to relax this rule to also allow mapping of supplemental
> > groups (1:1) of the caller?
> >
> > Thanks.
> >
> > --
> > Dmitry
>
> Hi,
>
> Is there a use case where adding those to /etc/subgid is onerous?
> (There probably is, just would like to see yours)
We on Chrome OS limit number of suid binaries installed on the system,
so newgidmap does not have necessary privileges to carry out this
operation. Also we are looking for a solution that we can use with our
minijail package where spawning additional binary is challenging even
if it was suid.
Thanks.
--
Dmitry
--
Dmitry
On Thu, Mar 28, 2019 at 11:30:52AM -0700, Dmitry Torokhov wrote:
> Hi Serge,
>
> On Thu, Mar 28, 2019 at 11:05 AM Serge E. Hallyn <[email protected]> wrote:
> >
> > On Thu, Feb 28, 2019 at 11:27:38AM -0800, Dmitry Torokhov wrote:
> > > Hi Eric,
> > >
> > > Currently, unless caller has CAP_SETGID in parent namespace, we can
> > > only map effective group id in the new user namespace. Would it be
> > > possible to relax this rule to also allow mapping of supplemental
> > > groups (1:1) of the caller?
> > >
> > > Thanks.
> > >
> > > --
> > > Dmitry
> >
> > Hi,
> >
> > Is there a use case where adding those to /etc/subgid is onerous?
> > (There probably is, just would like to see yours)
>
> We on Chrome OS limit number of suid binaries installed on the system,
> so newgidmap does not have necessary privileges to carry out this
<shrug> good goal in general so long as you don't take a few huge
monolithic suid binaries instad of more simpler ones :)
> operation. Also we are looking for a solution that we can use with our
> minijail package where spawning additional binary is challenging even
> if it was suid.
Ok. So fwiw I think what you propose should be ok. I think you should
post a patch to do it. It's very possible that seeing that patch will
remind us of the reason why it *is* a bad idea, but seeing the patch may
be a required shock to elicit that memory.
-serge
On Thu, Mar 28, 2019 at 11:37 AM Serge E. Hallyn <[email protected]> wrote:
>
> On Thu, Mar 28, 2019 at 11:30:52AM -0700, Dmitry Torokhov wrote:
> > Hi Serge,
> >
> > On Thu, Mar 28, 2019 at 11:05 AM Serge E. Hallyn <[email protected]> wrote:
> > >
> > > On Thu, Feb 28, 2019 at 11:27:38AM -0800, Dmitry Torokhov wrote:
> > > > Hi Eric,
> > > >
> > > > Currently, unless caller has CAP_SETGID in parent namespace, we can
> > > > only map effective group id in the new user namespace. Would it be
> > > > possible to relax this rule to also allow mapping of supplemental
> > > > groups (1:1) of the caller?
> > > >
> > > > Thanks.
> > > >
> > > > --
> > > > Dmitry
> > >
> > > Hi,
> > >
> > > Is there a use case where adding those to /etc/subgid is onerous?
> > > (There probably is, just would like to see yours)
> >
> > We on Chrome OS limit number of suid binaries installed on the system,
> > so newgidmap does not have necessary privileges to carry out this
>
> <shrug> good goal in general so long as you don't take a few huge
> monolithic suid binaries instad of more simpler ones :)
>
> > operation. Also we are looking for a solution that we can use with our
> > minijail package where spawning additional binary is challenging even
> > if it was suid.
>
> Ok. So fwiw I think what you propose should be ok. I think you should
> post a patch to do it. It's very possible that seeing that patch will
> remind us of the reason why it *is* a bad idea, but seeing the patch may
> be a required shock to elicit that memory.
OK, I will cook up something.
Thanks.
--
Dmitry