Vasily Kulikov <segoon@xxxxxxxxxxxx> writes: > Hi Eric, > > On Tue, Jan 22, 2013 at 01:11 -0800, 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. > > Why patch shadow tools? Why not implement the feature as a PAM > module? I need hooks into useradd and userdel to managed the subordinate user ids and group ids when users are added and removed from the system. PAM doesn't appear to have any hooks like that at all. Furthermore shadow-utils is where other uids and gids are allocated and it makes sense to keep the allocation functions together so if it makes sense they can talk to each other > All other capabilities granting things are implemented as PAM modules: > pam_group, pam_namespace, pam_cap. Except when you want to program the mapping is not at login time. Programming the mapping needs to happen when a user namespace is set up. The admin of the user namespace knows which uids and gids will be used in that user namespace. The system is configured to know which uids and gids that user can map to. > I don't see why it cannot be fully > modularized, a common admin doesn't need multiple uid/gid user_ns for > non-root users at all, why patch basic tools? The common admin doesn't _yet_ need multiple uid/gid user_ns for non-root users. As of linux 3.8 you don't need any special privilege to create a user namespace. Once you have a user namespace you can create other namespaces. This is good for building containers for light weigh virtualization and testing and this is good for sandboxing subprocess. The chrome-browser sandbox uses a setuid application to set a up namespaces for this purpose. A couple of extra uids should make the sandboxing uses much more complete. Not to mention the advantages of being able to run another distro in a lighter more portable form than hardware virtualization. Given the habit of the distributions of enabling everything possible I believe it will become common for distributions to allocate multiple uids and gids to users by default. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers