[0/10] User namespaces: introduction

Serge E. Hallyn serue at us.ibm.com
Mon Aug 25 12:51:24 PDT 2008

Quoting Eric W. Biederman (ebiederm at xmission.com):
> "Serge E. Hallyn" <serue at us.ibm.com> writes:
> > It definately seems to make sense in terms of the security
> > implications.  And solving this before the filesystem handlers seems
> > to make sense too.  Although I would like to get the first 3 patches upstream
> > pretty soon, as I believe they are proper fixes.
> Reasonable.  I'm not certain about free_user continuing to be an inline
> function as it seems a bit non-trivial, but otherwise that sounds correct.

Great, I'll fix that and resend and ask for inclusion.

So based on your input, here is how I'm seeing the next iteration of
usernamespace-filesystem interaction semantics:

	(X,Y) = (userns X, uid Y)
	(0,500) creates (1,0) and (1,1000)
	(1,1000) creates a file /foo/bar
		inode->i_uid = 1000
		inode->i_userns = 1  (we use the mount-provided userns, right?)
			i_userns storing is per-fs, but probably uses xattr)
		the fs stores the fact that (0,500) owns userns 1
			this might be stored just in /etc/userns.conf,
			and parsed at mount time)
	 when (1,1001) looks up /foo/bar, he sees owner=1000
	 when (0,501) looks up /foo/bar, he sees owner=500
	 when (0,501) creates (2,0) and (2,0) looksup /foo/bar,
		he sees owner=0, mode bits clear except the 'other' bits

Put user_ns in struct inode so simple userid mapping can be done
in generic code.

Here is a weirdness:  If (0,500) creates some files as (1,1000)
under /home/hallyn/containers/vs1.  Now the system is rebooted, and the
/etc/userns.conf for some reason is not loaded.  Now when hallyn does
ls /home/hallyn/containers/vs1, he sees files owned by (0,0), with
only the 'other' permissions.  Now he can't make them setuid root so
it's no vulnerability.  Just a wart.

Is that what you had in mind?

But I'll still look at doing capabilities first like you were


More information about the Containers mailing list