Re: [0/10] User namespaces: introduction

[ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)]

"Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> writes:

> Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
>> "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> 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:
>
> if
> 	0=init_user_ns
> 	(X,Y) = (userns X, uid Y)
> 	(0,500) creates (1,0) and (1,1000)
> 	(1,1000) creates a file /foo/bar
> 	then
> 		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)

However we get that information.  Caching it per inode looks like the right
way to go.

> 		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

Sounds right.  Either that or we reserve a different uid for the purpose.
Still 0 appears to the be the traditional owner of unknown users in 
tarballs so it should work as long as don't accidentally grant privilege.

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

Yep.

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

Yep.

> Is that what you had in mind?

Yep.  That sounds right.  I think we have a little ways to go before we
have the persistence side of things liked but the in kernel side of the
semantics sounds correct.

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

Thanks.  That looks like a lot fewer conflicts.

Eric