[Pkg-shadow-devel] [test] newuidmap/newgidmap]

Eric W. Biederman ebiederm at xmission.com
Wed Jun 11 22:15:57 UTC 2014

Philippe Grégoire <gregoirep at hotmail.com> writes:

> Forgot to Cc to the list...
> -------- Message d'origine --------
> De : "Philippe Grégoire" <gregoirep at hotmail.com>
> Envoyé: 4 juin 2014 11:27:48 HAE
> À : Serge Hallyn <serge.hallyn at ubuntu.com>
> Objet : Re: [Pkg-shadow-devel] [test] newuidmap/newgidmap]
> On 4 juin 2014 09:20:19 HAE, Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
>>Quoting Philippe Grégoire (gregoirep at hotmail.com):
>>> After all, what I asked for was for a precision in
>>> newuidmap(1) stating that it is not meant to be used by privileged
>>users and advise to fallback on the kernel.
>>Would something like the following in the newuidmap manpage
>>help in your opinion?
>>"The newuidmap sets /proc/[pid]/uid_map based on it's command line
>>and the uids allowed in /etc/subuid.  The root user is not exempted
>>from the
>>requirement for a valid /etc/subuid entry."
> Brief and precise. It mentions the issue we've met. I think that, yes, it would help.
> I guess that the best practice, for toolsets, should be to ask the
> user if he's in subuid if newuidmap fails. And if the admin doesn't
> install uidmap/newuidmap, he won't be able to manage subuids... use
> unprivileged containers?
> Wouldn't it be more practical and secure if subuid was in the kernel
> (a la apparmor)? I know Eric has arguments against it and I don't know
> enough about those points to comment, but is it really not an
> appropriate path? Just asking...

Just to address the curiosity. At a very simple level in most cases
uids are persistent accross reboots, and uids are consistent across
machines.  So uid management is not a boot time property and the
/etc/subuid file or a database eqivalent must exist.

/etc/subuid coming over NIS or LDAP (if they are trusted) is an entirely
reasonable operation.

Today we partially load /etc/subuid on a case by case basis when a user
namespace is setup.

Now I can see it being possible to have something that reads the
entirety of /etc/subuid at boot time and loads it into the kernel,
or similarly something that loads the entirety of /etc/subuid for
a given user when that user logs in and loads that into the kernel.

I would not oppose an interface that allowed all of /etc/subuid and
/etc/subgid for that user to be preloaded upon login, assuming some of
the appropriate tools were modified to load such a list.  It would
require a bit more kernel memory but it would be more convinient to use
as ordinary programs could then just write to /proc/<pid>/uid_map.
It would also be backwards compatibile with what we are doing today,
so peoples existing investment would not be waisted.

I had not even considered doing that when I designed user namespaces.

That said I don't know if the advantage to doing something like that is
worth it at this point, as there already exists a solution that works,
and loading a users /etc/subuid entries at login would just be shifting
where userspace performs the work (to a pam module?).

I won't oppose such work but I don't have the time or inclination to
work on it myself.


More information about the Pkg-shadow-devel mailing list