[Pkg-shadow-devel] [PATCH 00/11] pkg-shadow support subordinate ids with user namespaces

[Serge Hallyn]

Quoting Glauber Costa (glommer at parallels.com):
> On 02/25/2013 06:34 PM, Serge Hallyn wrote:
> > Quoting Glauber Costa (glommer at parallels.com):
> >> On 02/22/2013 08:34 PM, Eric W. Biederman wrote:
> >>> Glauber Costa <glommer at parallels.com> writes:
> >>>
> >>>> On 01/22/2013 01:11 PM, Eric W. Biederman wrote:
> >>>>>
> >>>>> The kernel support for user namespaces allows ordinary users to use
> >>>>> multiple uids and gids if they can get a trusted program to tell the
> >>>>> kernel the set of subordinate uids and gids they are allowed to use.
> >>>>>
> >>>>> This is my work to make that trusted program.
> >>>>> Two new files are added /etc/subuid /etc/subgid that specify
> >>>>> ranges of uids and gids that users may uses.
> >>>>>
> >>>>> useradd, and newusers are modifed to add users to those files.
> >>>>>
> >>>>> userdel is modeifed to remove users from those files.
> >>>>>
> >>>>> usermod is modified to give manual control of what goes in those files.
> >>>>>
> >>>>> newuidmap and newgidmap read the new files and update
> >>>>> /proc/[pid]/uid_map and /proc/[pid]/gid_map respectively
> >>>>> as requested by their command line parameters and as allowed
> >>>>> by the /etc/subuid and /etc/subgid.
> >>>>>
> >>>>> The following patches are against the current developent trunk
> >>>>> of pkg-shadow svn rev 3745.  With minor tweaking of man/Makefile.am
> >>>>> these patches also apply to shadow 4.1.5.
> >>>>>
> >>>>> Eric W. Biederman (11):
> >>>>>       Documentation for /etc/subuid and /etc/subgid
> >>>>>       login.defs.5: Document the new variables in login.defs
> >>>>>       Implement commonio_append.
> >>>>>       Add backend support for suboridnate uids and gids
> >>>>>       Implement find_new_sub_uids find_new_sub_gids
> >>>>>       userdel: Add support for removing subordinate user and group ids.
> >>>>>       useradd: Add support for subordinate user identifiers
> >>>>>       Add support for detecting busy subordinate user ids
> >>>>>       usermod: Add support for subordinate uids and gids.
> >>>>>       newusers: Add support for assiging subordinate uids and gids.
> >>>>>       newuidmap,newgidmap: New suid helpers for using subordinate uids and gids
> >>>>
> >>>> Hi,
> >>>>
> >>>> Is there any intention to merge this (or any later version thereof) ?
> >>>> I intend to start excluding uid ranges for containers usage in OpenVZ,
> >>>> and support for that in tooling would come in handy.
> >>>
> >>> I don't know what the state of the main pkg-shadow package is.  I have
> >>> heard anything and the repository seems to have been dormant since the
> >>> last release almost a year ago.
> >>>
> >>> However the last I heard Serge was working on getting these changes into
> >>> Ubuntu.
> >>>
> >>> So the intention is to get this code merged but I don't know what more
> >>> needs to be done at this point.
> >>>
> >> I understand, this was more a question for the package maintainers.
> >> It would be interesting for us to have those changes more widely
> >> available than just @Ubuntu
> > 
> > Well, I would aim to get it into Debian, from where it should make it
> > into all its downstreams eventually...  But I know that's not what you
> > mean :)
> > 
> > Note that the core of this really isn't a big deal, and you can easily
> > implement your own distro-independent wrappers.  Just provide an easy
> > tool for admins to assign subuids to users, and a small setuid-root
> > binary to allow users, subject to those constraints, to write to
> > /proc/$$/uid_maps.
> > 
> > Shadow integration will be nice, but for your use case you should be
> > able to by-step it until shadow integration is complete.
> > 
> 
> Well, the main problem is that I don't talk on behalf of any distro. We
> distribute OpenVZ, and would like to create containers such that each
> container has its own user range - all that without having the
> containers users conflicting with users created by useradd's normal
> operation.
> 
> I am *hoping* that by selecting ranges high enough I will avoid
> conflicts at least in the beginning, but it is a bit of guesswork.

Oh, it's not too hard to uidmapshift a container, so if not having
conflicting ranges with what is auto-handed-out by distros, I'm
not saying don't worry about it but it shouldn't be that big of a
deal.

I don't recall whether Eric's patches included a system-wide 'start
subuid ranges here' number.  If not we should add oen, and you could
perhaps grab uids 50000-350000, and ask anyone using openvz, once
distros support subuids, to set 350001 as the lowest available subuid.

-serge