[0/10] User namespaces: introduction
Eric W. Biederman
ebiederm at xmission.com
Fri Aug 29 02:40:13 PDT 2008
"Serge E. Hallyn" <serue at us.ibm.com> writes:
> 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
>> > 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)
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.
> 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?
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
Thanks. That looks like a lot fewer conflicts.
More information about the Containers