On Fri, Dec 19, 2014 at 06:28:45AM -0600, Eric W. Biederman wrote:
> Karel Zak <kzak@xxxxxxxxxx> 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@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
