Re: [RFC][PATCH] unshare: Fix --map-root-user to work on new kernels

[Karel Zak <kzak@redhat.com>]

On Fri, Dec 19, 2014 at 06:28:45AM -0600, Eric W. Biederman wrote:
> Karel Zak <kzak@redhat.com> writes:
> >  What does it mean "allow" in /proc/self/setgroups? 
> >  
> >  If I good understand than /proc/self/gid_map is unwritable until the
> >  setgroups file is set to "deny", and "allow" means that gid_map is
> >  disabled at all, but setgroup() syscall is possible to use in the
> >  user namespace. Right?
> 
> No.
> 
> The current state is backwards compatible for root, and is a little
> weird but not that weird.
> 
> setgroups(2) is only callable with CAP_SETGID.
> CAP_SETGID in a user namespace (now) does not give you permission to
> call setgroups(2) (or any other system call) until after gid_map has
> been set.
> 
> /proc/self/setgroups controls the setgroups system call.
> "allow" means setgroups(2) is callable (permission checks permitting).
> "allow" is the default state of /proc/self/setgroups.
> "deny" means setgroups(2) is permanently disabled in the user namespace.
> "deny" is only settable while setgroups(2) is disabled (aka "deny" is
>        only settable before the gid_map is programmed)
> 
> gid_map is writable by root when setgroups(2) is enabled.
> gid_map becomes writable by "unprivileged" processes when setgroups(2)
> is permamently disabled.

Thanks, this is more obvious description.

[...]

> Fair enough.  A general control is reasonable, and not hard to support.
> Call it --setgroups=[allow|deny].

OK.

> I was wondering if we should have such a control and require it with
> --map-root-user to tell users their shell scripts fork login will break.

I think it's better to make --map-root-user usable without any another
command line option (as suggested by our unshare patch). In man page
we can describe all the relation between --map-root-user and new
--setgroups.

> For the prupose of breaking setups that will break a little later when
> setgroups(2) is called I don't think the option is worth it.
> 
> Just as a general knob I can see value in having a
> --setgroups=[allow|deny] knob.

Yes.

[...]

> The best would be to call setgroups(0, NULL) before entering the user
> namespace (so root can always clear their groups), and call setgroups(0,
> NULL) after entering the user namespace (as currently happens).  If both
> setgroups(0, NULL) calls fail then complain.
> 
> nsenter as currently constructed can not enter a user namespaces that
> does not map uid 0 and gid 0.   So not handling setgroups=deny for
> non-root users in seems reasonable.
> 
> What looks compelling to me is a --preserve-credentials option to
> nsenter that would not touch uids or gids.  A --preserve-credentials
> option will allow nsenter to enter all manner of user namespaces
> irrespective of they are configured.
> 
> Does that clear up the confusion?

Good question, we will see :-) ... I'm going to prepare some unshare
and nsenter patches next week.

Thanks Eric.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com