pkg-shadow support subordinate ids with user namespaces

lib/subordinateio.c new file +38 -0

+static void *subordinate_parse (const char *line)
+{
+	static struct subordinate_range range;
+	char rangebuf[1024];
+	int i;
+	char *cp;
+	char *fields[NFIELDS];
+
+	/*
+	 * Copy the string to a temporary buffer so the substrings can
+	 * be modified to be NULL terminated.
+	 */
+	if (strlen (line) >= sizeof rangebuf)
+		return NULL;	/* fail if too long */
+	strcpy (rangebuf, line);
+
+	/*
+	 * Save a pointer to the start of each colon separated
+	 * field.  The fields are converted into NUL terminated strings.
+	 */
+
+	for (cp = rangebuf, i = 0; (i < NFIELDS) && (NULL != cp); i++) {
+		fields[i] = cp;
+		while (('\0' != *cp) && (':' != *cp)) {
+			cp++;
+		}
+
+		if ('\0' != *cp) {
+			*cp = '\0';
+			cp++;
+		} else {
+			cp = NULL;
+		}
+	}
+
+	/*
+	 * There must be exactly NFIELDS colon separated fields or
+	 * the entry is invalid.  Also, fields must be non-blank.

Quoted 43 lines · Eric W. Biederman

lib/subordinateio.c new file +43 -0

+static void *subordinate_parse (const char *line)
+{
+	static struct subordinate_range range;
+	char rangebuf[1024];
+	int i;
+	char *cp;
+	char *fields[NFIELDS];
+
+	/*
+	 * Copy the string to a temporary buffer so the substrings can
+	 * be modified to be NULL terminated.
+	 */
+	if (strlen (line) >= sizeof rangebuf)
+		return NULL;	/* fail if too long */
+	strcpy (rangebuf, line);
+
+	/*
+	 * Save a pointer to the start of each colon separated
+	 * field.  The fields are converted into NUL terminated strings.
+	 */
+
+	for (cp = rangebuf, i = 0; (i < NFIELDS) && (NULL != cp); i++) {
+		fields[i] = cp;
+		while (('\0' != *cp) && (':' != *cp)) {
+			cp++;
+		}
+
+		if ('\0' != *cp) {
+			*cp = '\0';
+			cp++;
+		} else {
+			cp = NULL;
+		}
+	}
+
+	/*
+	 * There must be exactly NFIELDS colon separated fields or
+	 * the entry is invalid.  Also, fields must be non-blank.
+	 */
+	if (i != NFIELDS || *fields[0] == '\0' || *fields[1] == '\0' || *fields[2] == '\0')
+		return NULL;
+	range.owner = fields[0];
+	if (getulong (fields[1], &range.start) == 0)

lib/subordinateio.c line 95

Quoted 5 lines

lib/subordinateio.c new file +5 -0

+		return NULL;
+	if (getulong (fields[2], &range.count) == 0)
+		return NULL;
+
+	return ⦥

This function worries me, because you're returning local contents (both range itself, and range.owner).

In practice it doesn't matter but it looks worth fixing for the sake of long term maintenance.

Quoted 2 lines · Eric W. Biederman

In practice it doesn't matter but it looks worth fixing for the sake of long term maintenance.

I figured the users must all be ok, and in practice it would work out, but the fact remains subsequent function calls assigning to local stack can overwrite what you've returned. <shrug>

The rest of what I've looked over looked ok, thanks much!

Note you need the following bit on top of your patch to make newuidmap and newgidmap link against libselinux. Otherwise selinux-enabled builds (default in ubuntu) fail.

Index: shadow-4.1.5.1/src/Makefile.am
===================================================================

src/Makefile.am +2 -0

@@ -80,6 +80,8 @@
 endif
 
 chage_LDADD    = $(LDADD) $(LIBPAM_SUID) $(LIBAUDIT) $(LIBSELINUX)
+newuidmap_LDADD    = $(LDADD) $(LIBSELINUX)
+newgidmap_LDADD    = $(LDADD) $(LIBSELINUX)
 chfn_LDADD     = $(LDADD) $(LIBPAM) $(LIBSELINUX) $(LIBCRYPT_NOPAM) $(LIBSKEY) $(LIBMD)
 chgpasswd_LDADD = $(LDADD) $(LIBPAM_SUID) $(LIBSELINUX) $(LIBCRYPT)
 chsh_LDADD     = $(LDADD) $(LIBPAM) $(LIBSELINUX) $(LIBCRYPT_NOPAM) $(LIBSKEY) $(LIBMD)

Quoted 3 lines · Serge E. Hallyn

Note you need the following bit on top of your patch to make newuidmap and newgidmap link against libselinux. Otherwise selinux-enabled builds (default in ubuntu) fail.

Interesting. I can't imagine what brings in libselinux. But I am in favor of whatever works.

Functions for finding new subordinate uid and gids ranges for use with useradd.

[...]

(quoted diff) +3 -0

+int find_new_sub_gids (const char *owner,
+		       gid_t *range_start, unsigned long *range_count)
+{

(quoted diff) +28 -0

+
+	/* Is there a preferred range that works? */
+	if ((*range_count != 0) &&
+	    (*range_start >= min) &&
+	    (((*range_start) + (*range_count) - 1) <= max) &&
+	    is_sub_gid_range_free(*range_start, *range_count)) {
+		return 0;
+	}
+
+	if (max < (min + count)) {
+		(void) fprintf (stderr,
+				_("%s: Invalid configuration: SUB_GID_MIN (%lu), SUB_GID_MAX (%lu)\n"),
+			Prog, min, max);
+		return -1;
+	}
+	start = sub_gid_find_free_range(min, max, count);
+	if (start == (gid_t)-1) {
+		fprintf (stderr,
+		         _("%s: Can't get unique secondary GID range\n"),
+		         Prog);
+		SYSLOG ((LOG_WARN, "no more available secondary GIDs on the system"));
+		return -1;
+	}
+	*range_start = start;
+	*range_count = count;
+	return 0;
+}
+

libmisc/find_new_sub_uids.c new file +11 -0

new file mode 100644
index 0000000..f1720f9
 
[...]
 
+/*
+ * find_new_sub_uids - Find a new unused range of UIDs.
+ *
+ * If successful, find_new_sub_uids provides a range of unused
+ * user IDs in the [SUB_UID_MIN:SUB_UID_MAX] range.
+ * 
+ * Return 0 on success, -1 if no unused UIDs are available.
+ */
+int find_new_sub_uids (const char *owner,
+		       uid_t *range_start, unsigned long *range_count)
+{

libmisc/find_new_sub_uids.c new file +26 -0

+	/* Is there a preferred range that works? */
+	if ((*range_count != 0) &&
+	    (*range_start >= min) &&
+	    (((*range_start) + (*range_count) - 1) <= max) &&
+	    is_sub_uid_range_free(*range_start, *range_count)) {
+		return 0;
+	}
+
+	if (max < (min + count)) {
+		(void) fprintf (stderr,
+				_("%s: Invalid configuration: SUB_UID_MIN (%lu), SUB_UID_MAX (%lu)\n"),
+			Prog, min, max);
+		return -1;
+	}
+	start = sub_uid_find_free_range(min, max, count);
+	if (start == (uid_t)-1) {
+		fprintf (stderr,
+		         _("%s: Can't get unique secondary UID range\n"),
+		         Prog);
+		SYSLOG ((LOG_WARN, "no more available secondary UIDs on the system"));
+		return -1;
+	}
+	*range_start = start;
+	*range_count = count;
+	return 0;
+}

libmisc/find_new_sub_uids.c new file +9 -0

+	mappings = calloc(ranges, sizeof(*mappings));
+	if (!mappings) {
+		fprintf(stderr, _( "%s: Memory allocation failure\n"),
+			Prog);
+		exit(EXIT_FAILURE);
+	}
+
+	/* Gather up the ranges from the command line */
+	mapping = mappings;

Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/[email protected]):

Hi,

src/newuidmap.c line 57

Quoted 9 lines

src/newuidmap.c new file +9 -0

+static bool verify_range(struct passwd *pw, struct map_range *range)
+{
+	/* An empty range is invalid */
+	if (range->count == 0)
+		return false;
+
+	/* Test /etc/subuid */
+	if (have_sub_uids(pw->pw_name, range->lower, range->count))
+		return true;

I think the have_sub_uids() test should be skipped if we started out as root. Is there a reason not to do that?

Quoted 4 lines · Serge E. Hallyn

Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/[email protected]):

Hi,

Quoted 12 lines

src/newuidmap.c line 57

Quoted 9 lines

src/newuidmap.c new file +9 -0

+static bool verify_range(struct passwd *pw, struct map_range *range)
+{
+	/* An empty range is invalid */
+	if (range->count == 0)
+		return false;
+
+	/* Test /etc/subuid */
+	if (have_sub_uids(pw->pw_name, range->lower, range->count))
+		return true;

I think the have_sub_uids() test should be skipped if we started out as root. Is there a reason not to do that?

The only reason I can see for root to use this binary is if it a flavor of root that has dropped some capbilities. Is there a reason for root to use newuidmap and newgid map at all?

Otherwise I think it makes sense to enforce whatever the system choosen policy is on root, because root is opting in.

Eric
_______________________________________________
Containers mailing list Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

Quoted 19 lines · Eric W. Biederman

Quoted 16 lines · Serge E. Hallyn

Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/[email protected]):

Hi,

Review

Quoted 9 lines

(quoted diff) +9 -0

+static bool verify_range(struct passwd *pw, struct map_range *range)
+{
+	/* An empty range is invalid */
+	if (range->count == 0)
+		return false;
+
+	/* Test /etc/subuid */
+	if (have_sub_uids(pw->pw_name, range->lower, range->count))
+		return true;

I think the have_sub_uids() test should be skipped if we started out as root. Is there a reason not to do that?

Quoted 3 lines

The only reason I can see for root to use this binary is if it a flavor of root that has dropped some capbilities. Is there a reason for root to use newuidmap and newgid map at all?

Of course. It keeps things simpler for creating mapped containers. Otherwise we have to special-case the "i am root" vs "i am not root" case when untarring a rootfs for a container.

Quoted 20 lines · Serge Hallyn

Quoted 19 lines · Eric W. Biederman

Quoted 16 lines · Serge E. Hallyn

Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/[email protected]):

Hi,

Review

Quoted 9 lines

(quoted diff) +9 -0

+static bool verify_range(struct passwd *pw, struct map_range *range)
+{
+	/* An empty range is invalid */
+	if (range->count == 0)
+		return false;
+
+	/* Test /etc/subuid */
+	if (have_sub_uids(pw->pw_name, range->lower, range->count))
+		return true;

I think the have_sub_uids() test should be skipped if we started out as root. Is there a reason not to do that?

Quoted 7 lines

Quoted 3 lines

The only reason I can see for root to use this binary is if it a flavor of root that has dropped some capbilities. Is there a reason for root to use newuidmap and newgid map at all?

Of course. It keeps things simpler for creating mapped containers. Otherwise we have to special-case the "i am root" vs "i am not root" case when untarring a rootfs for a container.

I guess my practical question is don't we want to reserve a range of subuid's for root owned containers as well. Just so that we know someone is using those uids and we don't get them allocated to another purpose?

Or am I missing something here?

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.

I am waaaay behind on email.

Quoted 4 lines · Eric W. Biederman

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.

Could you give an example of this? (If this takes off I'll probably want to add support to toybox, but from the man pages I don't understand what it's for.)

Quoted 3 lines

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.

They must use a contiguous range with count, not
"landley:4000-4999,6103,7002-7005"?

Quoted 4 lines

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.

Quoted 4 lines

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.

I'm not finding uid_map and gid_map in Documentation/filesystems/proc.txt, is this a pending patch?

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.

Hi Eric,

Quoted 19 lines · Eric W. Biederman

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.

Quoted 3 lines

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?

All other capabilities granting things are implemented as PAM modules:
pam_group, pam_namespace, pam_cap.

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?

Quoted 2 lines · Vasily Kulikov

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

Quoted 2 lines

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.

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

Quoted 24 lines · Eric W. Biederman

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.

Quoted 12 lines

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.

Quoted 38 lines · Glauber Costa

Quoted 24 lines · Eric W. Biederman

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.

Quoted 12 lines

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

Quoted 5 lines

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.

Quoted 53 lines · Eric W. Biederman

Quoted 38 lines · Glauber Costa

Quoted 24 lines · Eric W. Biederman

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.

Quoted 12 lines

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

Quoted 5 lines

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.

Quoted 3 lines

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

Quoted 54 lines · Glauber Costa

Quoted 53 lines · Eric W. Biederman

Quoted 38 lines · Glauber Costa

Quoted 24 lines · Eric W. Biederman

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.

Quoted 12 lines

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

Quoted 5 lines

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.

Quoted 6 lines

Quoted 3 lines

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.

Quoted 66 lines · Serge Hallyn

Quoted 54 lines · Glauber Costa

Quoted 53 lines · Eric W. Biederman

Quoted 38 lines · Glauber Costa

Quoted 24 lines · Eric W. Biederman

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.

Quoted 12 lines

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

Quoted 5 lines

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.

Quoted 6 lines

Quoted 3 lines

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 :)

Quoted 9 lines

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.

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.

Quoted 38 lines · Glauber Costa

Quoted 24 lines · Eric W. Biederman

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.

Quoted 12 lines

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

Quoted 5 lines

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.

Eric

_______________________________________________
Containers mailing list Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

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
---

Quoted 24 lines · Eric W. Biederman

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.

Quoted 13 lines

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
---

OK, now we're ready for this.

Eric, I have no skills to decide whether your patches can be included or not. My proposal is to go ahead and include them in the upcomign 4.2 release, that will be compiled and uploaded in Debian as soon as released, so that it gets extensive testing.

We now have an "upstream" git repository at

http://github.com/shadow-maint/shadow.git

Would you mind pushing your set of patches there?

That requires an account on github and include you in the project members (Serge Hallyn can do that).

I would prefer this over committing/pushing myself.

I really apologize for the too long delay working on this. We now need to revive shadow's development.

Quoted 10 lines · Christian PERRIER

Quoted 9 lines · Eric W. Biederman

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.

Quoted 5 lines

Quoted 5 lines

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.

Quoted 10 lines

Quoted 10 lines

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.

Quoted 7 lines

Quoted 7 lines

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.

Quoted 5 lines

Quoted 5 lines

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

Quoted 14 lines

Quoted 1 line

---

OK, now we're ready for this.

Eric, I have no skills to decide whether your patches can be included or not. My proposal is to go ahead and include them in the upcomign 4.2 release, that will be compiled and uploaded in Debian as soon as released, so that it gets extensive testing.

We now have an "upstream" git repository at

http://github.com/shadow-maint/shadow.git

Quoted 8 lines

Would you mind pushing your set of patches there?

That requires an account on github and include you in the project members (Serge Hallyn can do that).

I would prefer this over committing/pushing myself.

I really apologize for the too long delay working on this. We now

need

Quoted 1 line

to revive shadow's development.

Understood.

At this point Serge has taken over stewardship of those patches and has a version with all of the known bug fixes applied that has been reviewed
and included in Ubuntu. So I expect the most responsible way is to just
pull the branch with those changes that is in Ubuntu.

Serge does that sound right?

Eric

Quoted 76 lines · ebiederm-aS9lmoZGLiVWk0Htik3J/[email protected] wrote:

Quoted 10 lines · Christian PERRIER

Quoted 9 lines · Eric W. Biederman

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.

Quoted 5 lines

Quoted 5 lines

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.

Quoted 10 lines

Quoted 10 lines

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.

Quoted 7 lines

Quoted 7 lines

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.

Quoted 5 lines

Quoted 5 lines

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

Quoted 14 lines

Quoted 1 line

---

OK, now we're ready for this.

Eric, I have no skills to decide whether your patches can be included or not. My proposal is to go ahead and include them in the upcomign 4.2 release, that will be compiled and uploaded in Debian as soon as released, so that it gets extensive testing.

We now have an "upstream" git repository at

http://github.com/shadow-maint/shadow.git

Quoted 8 lines

Would you mind pushing your set of patches there?

That requires an account on github and include you in the project members (Serge Hallyn can do that).

I would prefer this over committing/pushing myself.

I really apologize for the too long delay working on this. We now

need

Quoted 1 line

to revive shadow's development.

Understood.

At this point Serge has taken over stewardship of those patches and has a version with all of the known bug fixes applied that has been reviewed
and included in Ubuntu. So I expect the most responsible way is to just
pull the branch with those changes that is in Ubuntu.

Quoted 3 lines

Serge does that sound right?

Eric

Sorry think I just sent a private reply. To repeat, I can do this when I'm back at a kbd, maybe Friday, definately Monday.

I rebased and pushed the patchset yesterday.

Hi,

Quoted 2 lines · On Tue, Aug 06, 2013 at 02:54:03PM +0000…

I rebased and pushed the patchset yesterday.

Thanks (this removes me the burden of finding how to merge a branch).

I started to review and read about user namespaces (thanks to Michael!) o
Here are some questions/remarks:

1] It would be nice to be able to disable the new tools / manpages /
options on some systems (i.e. they only make sense on Linux, with recent Kernel). It would be OK for me if it is enabled by default. Do you agree?

2] I think we can assume that UID/GIDs are (at least) 32 bits, right?
(or at least when the feature is not disabled - see point 1)

3] For PAM versions of shadow, I think it would be nice to authenticate
the caller of newuidmap / newgidmap. Do you agree?

4] What happens when newuidmap / newgidmap are used within a new namespace?
Is there a risk to do something wrong by recursively creating shells in cascaded namespace and using these tools? (I don't think so) Is there a way to enforce that it would only be used in the top-most namespace? (Maybe it's not needed to forbid it)

It would be worth to have at least a paragraph about it in the manpages. (i.e. IDs in /etc/sub*id are according to the caller's namespace)

5] It would be worth documenting on which processes newuidmap / newgidmap
can act.
With newuidmap, an user can set the UID mapping for any process with restrictions on the process and on the requested ranges. We could also mention that the kernel enforce also restriction (5 lines at most; can only be written once)

5.1] The restriction on the caller or processes seems to be the followings:

    if ((getuid() != pw->pw_uid) ||   // not needed (already enforced
                                      // by get_my_pwent()) - but does not
                                      // harm.
        (getgid() != pw->pw_gid) ||   // I don't understand this
                                      // restriction. If I execute a
                                      // shell with another GID (e.g. using
                                      // newgrp) why should it be denied?

        (pw->pw_uid != st.st_uid) ||
        (pw->pw_gid != st.st_gid)) {  // Is it also needed? What would be
                                      // the problem

6] Documenting the APIs would be useful. Especially the ones in
lib/subordinateio.c (after 5 minutes, I get lost with the is_range_free, range_exists, find_range, have_range, ...)

7] I'm not sure about the handling of limits of ranges.
* First, I'm not sure what is intended. (e.g. is SUB_GID_MAX included in the range)
* In libmisc/find_new_sub_uids.c: Is it intended to forbid min == max (I'm not claiming this is very useful, but if SUB_GID_MIN=SUB_GID_MAX and SUB_GID_COUNT is set to 1, this should be valid to set a single mapping for one UID)

* In find_free_range(), min==max is also forbidden.
* In find_free_range(), the check (high > low) forbids to reuse a hole of just 1 UID starting at min
...

8] Is there a need to check somewhere that that UID_MAX < SUB_UID_MIN in
login.defs? Or is it valid to have overlaps?

9] Add manpage NOTE that newuidmap / newgidmap can be used only once on a
given process?

10] useradd adds sub*id when the /etc/sub*id files are present, right?
Is it also correct/intended for system users?
I think there should be options to enable or disable the feature. (I would have chosen the first solution, but I can also understand that we consider that the presence of the files is a request to use the feature by default)

11] Ranges will be defined for new users. Do you think there would be a
need for another tool to initialize a system for this feature? (similar to pwconv)

12] There could be additions in pwck:
* check that users in /etc/sub*id exist
* check overlaps?

* check overlaps with UIDs?
* ...

I do not think that they are blocking points. (i.e. there could be a release without a solution)

Quoted 8 lines · Nicolas François

Hi,

Quoted 2 lines · On Tue, Aug 06, 2013 at 02:54:03PM +0000, [email protected] wrote:

I rebased and pushed the patchset yesterday.

Thanks (this removes me the burden of finding how to merge a branch).

Quoted 8 lines

I started to review and read about user namespaces (thanks to Michael!) o
Here are some questions/remarks:

1] It would be nice to be able to disable the new tools / manpages /
options on some systems (i.e. they only make sense on Linux, with recent Kernel). It would be OK for me if it is enabled by default. Do you agree?

Makes sense.

Quoted 2 lines

2] I think we can assume that UID/GIDs are (at least) 32 bits, right?
(or at least when the feature is not disabled - see point 1)

Hm, what about systems compiled with CONFIG_UID16?

Quoted 2 lines

3] For PAM versions of shadow, I think it would be nice to authenticate
the caller of newuidmap / newgidmap. Do you agree?

I'm not sure what you mean. Do you mean that pam_something.so could otherwise call newuidmap/newgidmap before being authenticated?

Quoted 5 lines

4] What happens when newuidmap / newgidmap are used within a new namespace?
Is there a risk to do something wrong by recursively creating shells in cascaded namespace and using these tools? (I don't think so) Is there a way to enforce that it would only be used in the top-most namespace? (Maybe it's not needed to forbid it)

The kernel user namespace implementation is designed to support nesting.

Actually I'm not 100% sure, but I think that setuid-root is currently only honored in the initial user namespace. If that were changed, then calling newuidmap from a child user namespace would only give the caller privilege over his child user namespace. Therefore he could only delegate userids from his own (non-init) namespace to his own descendent user namespaces.

calling newuidmap on a pid in the initial user namespace results in -EPERM (as otherwise an unprivileged user could remap privileged tasks to his permitted subuids :)

Quoted 3 lines

It would be worth to have at least a paragraph about it in the manpages. (i.e. IDs in /etc/sub*id are according to the caller's namespace)

Agreed.

Quoted 6 lines

5] It would be worth documenting on which processes newuidmap / newgidmap
can act.
With newuidmap, an user can set the UID mapping for any process with restrictions on the process and on the requested ranges. We could also mention that the kernel enforce also restriction (5 lines at most; can only be written once)

Note that there are under-development very detailed manpages for namespaces(7) and user_namespaces(7). I agree the newuidmap manpage should document what it can act, a one or two line addition to DESCRIPTION. Then it should simply refer to the other manpages.

Quoted 8 lines

5.1] The restriction on the caller or processes seems to be the followings:

    if ((getuid() != pw->pw_uid) ||   // not needed (already enforced
                                      // by get_my_pwent()) - but does not
                                      // harm.
        (getgid() != pw->pw_gid) ||   // I don't understand this
                                      // restriction. If I execute a
                                      // shell with another GID (e.g. using
                                      // newgrp) why should it be denied?

I'm not sure. I don't know whether Eric was following conventions elsewhere in the code, or had specific attacks in mind.

Quoted 3 lines

        (pw->pw_uid != st.st_uid) ||
        (pw->pw_gid != st.st_gid)) {  // Is it also needed? What would be
                                      // the problem

IIUC uid 1000, authorized to use subuids 100000-110000, could otherwise use newuidmap to remap a namespace owned by uid 1001.

Quoted 3 lines

6] Documenting the APIs would be useful. Especially the ones in
lib/subordinateio.c (after 5 minutes, I get lost with the is_range_free, range_exists, find_range, have_range, ...)

In-line (above each function) or elsewhere?

Quoted 7 lines

7] I'm not sure about the handling of limits of ranges.
* First, I'm not sure what is intended. (e.g. is SUB_GID_MAX included in the range)
* In libmisc/find_new_sub_uids.c: Is it intended to forbid min == max (I'm not claiming this is very useful, but if SUB_GID_MIN=SUB_GID_MAX and SUB_GID_COUNT is set to 1, this should be valid to set a single mapping for one UID)

Agreed that sounds like it should be allowed.

Quoted 4 lines

* In find_free_range(), min==max is also forbidden.
* In find_free_range(), the check (high > low) forbids to reuse a hole of just 1 UID starting at min
...

Quoted 2 lines

8] Is there a need to check somewhere that that UID_MAX < SUB_UID_MIN in
login.defs? Or is it valid to have overlaps?

That sounds like a dangerous condition to me, and I had assumed it was already checked somewhere.

Quoted 2 lines

9] Add manpage NOTE that newuidmap / newgidmap can be used only once on a
given process?

Agreed.

Quoted 6 lines

10] useradd adds sub*id when the /etc/sub*id files are present, right?
Is it also correct/intended for system users?
I think there should be options to enable or disable the feature. (I would have chosen the first solution, but I can also understand that we consider that the presence of the files is a request to use the feature by default)

Not sure on both of those. Actually given the (artificial) definition of a system user in useradd(8), it sounds to me like subuids could be useful for system users on a system where tasks get started in a userns by boot scripts using a system userid.

Quoted 3 lines

11] Ranges will be defined for new users. Do you think there would be a
need for another tool to initialize a system for this feature? (similar to pwconv)

Do you mean to add ranges for existing users?

Quoted 3 lines

12] There could be additions in pwck:
* check that users in /etc/sub*id exist
* check overlaps?

Overlaps may actually be a feature in some cases, as a way to allow users to share data.

Quoted 5 lines

* check overlaps with UIDs?
* ...

I do not think that they are blocking points. (i.e. there could be a release without a solution)

I'll wait for comments or ("no time for a comment") on any of these from Eric, then look at addressing those that I can.

Quoted 16 lines · Serge Hallyn

Quoted 14 lines · Nicolas François

Quoted 2 lines · On Tue, Aug 06, 2013 at 02:54:03PM +0000…

I rebased and pushed the patchset yesterday.

Thanks (this removes me the burden of finding how to merge a branch).

I started to review and read about user namespaces (thanks to Michael!) o
Here are some questions/remarks:

1] It would be nice to be able to disable the new tools / manpages /
options on some systems (i.e. they only make sense on Linux, with recent Kernel). It would be OK for me if it is enabled by default. Do you agree?

Quoted 6 lines

Makes sense.

Quoted 2 lines

2] I think we can assume that UID/GIDs are (at least) 32 bits, right?
(or at least when the feature is not disabled - see point 1)

Hm, what about systems compiled with CONFIG_UID16?

Quoted 5 lines

Quoted 2 lines

3] For PAM versions of shadow, I think it would be nice to authenticate
the caller of newuidmap / newgidmap. Do you agree?

I'm not sure what you mean. Do you mean that pam_something.so could otherwise call newuidmap/newgidmap before being authenticated?

It sounded to me like he was suggesting newuidmap/newgidmap should make an appropriate pam call. I am not familiar with that part of pam so I don't know what would be an appropriate pam call.

The closest analog I can think of is newgrp, and to my knowledge newgrp does not cal into pam.

Quoted 15 lines

Quoted 5 lines

4] What happens when newuidmap / newgidmap are used within a new namespace?
Is there a risk to do something wrong by recursively creating shells in cascaded namespace and using these tools? (I don't think so) Is there a way to enforce that it would only be used in the top-most namespace? (Maybe it's not needed to forbid it)

The kernel user namespace implementation is designed to support nesting.

Actually I'm not 100% sure, but I think that setuid-root is currently only honored in the initial user namespace. If that were changed, then calling newuidmap from a child user namespace would only give the caller privilege over his child user namespace. Therefore he could only delegate userids from his own (non-init) namespace to his own descendent user namespaces.

Quoted 3 lines

calling newuidmap on a pid in the initial user namespace results in -EPERM (as otherwise an unprivileged user could remap privileged tasks to his permitted subuids :)

There are slightly funny things with setuid and setcap.

The short version however is that once in a user namespace you will never have more permissions than your the root user in your user namespace.

So from the outside of the user namespace you can't do anything bad even with nesting. Aka there is no defined means to escapte privileges from inside a user namespace to anything privileged outside a user namespace.

From inside the user namespace you can only follow /etc/subuid or /etc/subgid (when setting up a nested user namespace). And if that is a concern the root user of a user namespace can just create a new mount namespace and mount over the top of them.

So I don't see anything to concern about.

Quoted 5 lines

Quoted 3 lines

It would be worth to have at least a paragraph about it in the manpages. (i.e. IDs in /etc/sub*id are according to the caller's namespace)

Agreed.

Quoted 7 lines

Quoted 6 lines

5] It would be worth documenting on which processes newuidmap / newgidmap
can act.
With newuidmap, an user can set the UID mapping for any process with restrictions on the process and on the requested ranges. We could also mention that the kernel enforce also restriction (5 lines at most; can only be written once)

Quoted 4 lines

Note that there are under-development very detailed manpages for namespaces(7) and user_namespaces(7). I agree the newuidmap manpage should document what it can act, a one or two line addition to DESCRIPTION. Then it should simply refer to the other manpages.

Yeah. I should follow up and see what has happend with all of that.

Quoted 9 lines

Quoted 8 lines

5.1] The restriction on the caller or processes seems to be the followings:

    if ((getuid() != pw->pw_uid) ||   // not needed (already enforced
                                      // by get_my_pwent()) - but does not
                                      // harm.
        (getgid() != pw->pw_gid) ||   // I don't understand this
                                      // restriction. If I execute a
                                      // shell with another GID (e.g. using
                                      // newgrp) why should it be denied?

Quoted 2 lines

I'm not sure. I don't know whether Eric was following conventions elsewhere in the code, or had specific attacks in mind.

I don't have the context handy, but I think that was general paranoia. On the lines of if something strange is going on don't allow it.

Quoted 1 line

Quoted 1 line

        (pw->pw_uid != st.st_uid) ||

Quoted 5 lines

Quoted 2 lines

        (pw->pw_gid != st.st_gid)) {  // Is it also needed? What would be
                                      // the problem

IIUC uid 1000, authorized to use subuids 100000-110000, could otherwise use newuidmap to remap a namespace owned by uid 1001.

Quoted 5 lines

Quoted 3 lines

6] Documenting the APIs would be useful. Especially the ones in
lib/subordinateio.c (after 5 minutes, I get lost with the is_range_free, range_exists, find_range, have_range, ...)

In-line (above each function) or elsewhere?

Quoted 8 lines

Quoted 7 lines

7] I'm not sure about the handling of limits of ranges.
* First, I'm not sure what is intended. (e.g. is SUB_GID_MAX included in the range)
* In libmisc/find_new_sub_uids.c: Is it intended to forbid min == max (I'm not claiming this is very useful, but if SUB_GID_MIN=SUB_GID_MAX and SUB_GID_COUNT is set to 1, this should be valid to set a single mapping for one UID)

Quoted 6 lines

Agreed that sounds like it should be allowed.

Quoted 4 lines

* In find_free_range(), min==max is also forbidden.
* In find_free_range(), the check (high > low) forbids to reuse a hole of just 1 UID starting at min
...

Scratching my head. When ranges are bounded by two numbers it gets weird. All I remember for certain is I deliberately choose the file format of uid, length so that it would be hard to make off by one mistakes in the files.

Quoted 5 lines

Quoted 2 lines

8] Is there a need to check somewhere that that UID_MAX < SUB_UID_MIN in
login.defs? Or is it valid to have overlaps?

That sounds like a dangerous condition to me, and I had assumed it was already checked somewhere.

These were fairly arbitrary defines, with no sanity checks and I didn't add any. I just had sensible defaults. As that tends to be the unix way. You can have rope to shoot yourself if you really want it.

I really have no opinion on the need for sanity checks one way or another.

Quoted 12 lines

Quoted 2 lines

9] Add manpage NOTE that newuidmap / newgidmap can be used only once on a
given process?

Agreed.

Quoted 6 lines

10] useradd adds sub*id when the /etc/sub*id files are present, right?
Is it also correct/intended for system users?
I think there should be options to enable or disable the feature. (I would have chosen the first solution, but I can also understand that we consider that the presence of the files is a request to use the feature by default)

Quoted 4 lines

Not sure on both of those. Actually given the (artificial) definition of a system user in useradd(8), it sounds to me like subuids could be useful for system users on a system where tasks get started in a userns by boot scripts using a system userid.

I believe the question was. If /etc/subuid does not exist and we add a new user do we want to add an entry in /etc/subuid. Similarly for /etc/subgid.

I followed convention in shadow and figured that if /etc/subuid and /etc/subgid are not present we don't want to add subuids and subgids.

I don't expect we want to add subuids and subgids for system users by default but as Serge says there may be instances where we want to add them manually.

Quoted 5 lines

Quoted 3 lines

11] Ranges will be defined for new users. Do you think there would be a
need for another tool to initialize a system for this feature? (similar to pwconv)

Do you mean to add ranges for existing users?

I believe it was either useradd or usermod that I modified so that I could add subuids and subgids for an existing user manually.

As for upgrades I don't know. Serge with your distro hat on do you see a use for automatically giving user on a system subids and subgids when they upgrade versions of shadow?

Quoted 6 lines

Quoted 3 lines

12] There could be additions in pwck:
* check that users in /etc/sub*id exist
* check overlaps?

Overlaps may actually be a feature in some cases, as a way to allow users to share data.

I know I deliberately allowed (but would never create by default) multiple users having access to the same range of subordinate uids.

Shared read-only system images may benefit from such a practice.

In a similar vein there may be uses of being able to log in to a system with what is ordinarily a subordinate uid.

The distinction is a distinction of use not a distinction made in the kernel.

That said having overlaps is usually a mistake and a warning in the manual process may be called for in case someone simply didn't see something.

Quoted 6 lines

Quoted 5 lines

* check overlaps with UIDs?
* ...

I do not think that they are blocking points. (i.e. there could be a release without a solution)

Quoted 2 lines

I'll wait for comments or ("no time for a comment") on any of these from Eric, then look at addressing those that I can.

I hope that helps put some context to things. I am totally not looking at the userspace issues around newuidmap and newgidmap right now, and I appreciate others being able to look at it and make things better.

Hi Nekral,

This isn't a great urgency, but the final userns kernel support needed for this patchset to be useful should land in 3.9, so it isn't that far off. Do you have any objections to/feedback on this set? Would this be possible to get into Debian?

Quoted 6 lines · Serge E. Hallyn

Hi Nekral,

This isn't a great urgency, but the final userns kernel support needed for this patchset to be useful should land in 3.9, so it isn't that far off. Do you have any objections to/feedback on this set? Would this be possible to get into Debian?

In Debian jessie, maybe, if someone takes shadow over....or if Nicolas finds some motivation and time to work again on shadow.

In Debian wheezy, definitely no....but this is of no use, as Debian wheezy will certainly not use a 3.9 kernel.

diff -ur shadow-4.1.5.1.orig/src/usermod.c shadow-4.1.5.1/src/usermod.c

src/usermod.c +2 -2

@@ -410,9 +410,9 @@
 	(void) fputs (_("  -u, --uid UID                 new UID for the user account\n"), usageout);
 	(void) fputs (_("  -U, --unlock                  unlock the user account\n"), usageout);
 	(void) fputs (_("  -v, --add-subuids FIRST-LAST  add range of subordinate uids\n"), usageout);
-	(void) fputs (_("  -V, --del-subuids FIRST-LAST  remvoe range of subordinate uids\n"), usageout);
+	(void) fputs (_("  -V, --del-subuids FIRST-LAST  remove range of subordinate uids\n"), usageout);
 	(void) fputs (_("  -w, --add-subgids FIRST-LAST  add range of subordinate gids\n"), usageout);
-	(void) fputs (_("  -W, --del-subgids FIRST-LAST  remvoe range of subordinate gids\n"), usageout);
+	(void) fputs (_("  -W, --del-subgids FIRST-LAST  remove range of subordinate gids\n"), usageout);
 #ifdef WITH_SELINUX
 	(void) fputs (_("  -Z, --selinux-user SEUSER     new SELinux user mapping for the user account\n"), usageout);
 #endif				/* WITH_SELINUX */

@@ -993,9 +993,9 @@
 		};

Quoting Dwight Engen ([email protected]):
...

Quoted 17 lines

diff -ur shadow-4.1.5.1.orig/src/usermod.c shadow-4.1.5.1/src/usermod.c

src/usermod.c +2 -2

@@ -410,9 +410,9 @@
 	(void) fputs (_("  -u, --uid UID                 new UID for the user account\n"), usageout);
 	(void) fputs (_("  -U, --unlock                  unlock the user account\n"), usageout);
 	(void) fputs (_("  -v, --add-subuids FIRST-LAST  add range of subordinate uids\n"), usageout);
-	(void) fputs (_("  -V, --del-subuids FIRST-LAST  remvoe range of subordinate uids\n"), usageout);
+	(void) fputs (_("  -V, --del-subuids FIRST-LAST  remove range of subordinate uids\n"), usageout);
 	(void) fputs (_("  -w, --add-subgids FIRST-LAST  add range of subordinate gids\n"), usageout);
-	(void) fputs (_("  -W, --del-subgids FIRST-LAST  remvoe range of subordinate gids\n"), usageout);
+	(void) fputs (_("  -W, --del-subgids FIRST-LAST  remove range of subordinate gids\n"), usageout);
 #ifdef WITH_SELINUX
 	(void) fputs (_("  -Z, --selinux-user SEUSER     new SELinux user mapping for the user account\n"), usageout);
 #endif				/* WITH_SELINUX */

@@ -993,9 +993,9 @@
 		};

src/usermod.c line 1001

Quoted 10 lines

src/usermod.c +2 -2

 		while ((c = getopt_long (argc, argv,
 #ifdef WITH_SELINUX
-			                 "ac:d:e:f:g:G:hl:Lmop:R:s:u:UZ:",
+			                 "ac:d:e:f:g:G:hl:Lmop:R:s:u:Uv:V:w:W:Z:",
 #else				/* !WITH_SELINUX */
-			                 "ac:d:e:f:g:G:hl:Lmop:R:s:u:U",
+			                 "ac:d:e:f:g:G:hl:Lmop:R:s:u:Uv:V:w:W:",
 #endif				/* !WITH_SELINUX */
 			                 long_options, NULL)) != -1) {
 			switch (c) {

This hunk I've already emailed to Eric :) Note there is also a "break;" needed around line 1141.

Great to see more people testing this. Hopefully it will help to ease the mind of the maintainers in considering merging this.

Yes. It looks like we are going to have to setup a public repository somewhere to collect all of the changes and bug fixes. Not that I expect too many but clearly there are a few needed.

Quoted 3 lines · Eric W. Biederman

Yes. It looks like we are going to have to setup a public repository somewhere to collect all of the changes and bug fixes. Not that I expect too many but clearly there are a few needed.

That exists.

Shadow upstream (and Debian package) is maintained in an SVN repository hosted on alioth.debian.org.

I can make it as easy as possible to people to contribute by opening commit access there.

We can also, if that helps in attracting contributors, convert the repo to git (I will need help there because the repo has a quite long history and we want to keep it). I know that, nowadays, svn often

Hi,

I've not used svn at all, but would it help if I take a shot at this conversion (maintaining full history) putting the result into github for a first run?

Quoted 2 lines · Serge E. Hallyn

Hi,

Quoted 3 lines

I've not used svn at all, but would it help if I take a shot at this conversion (maintaining full history) putting the result into github for a first run?

Why not?

At first glance, I'd rather keep the "official" copy on alioth.debian.org