"Serge E. Hallyn" <serue@xxxxxxxxxx> writes: > Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): >> "Serge E. Hallyn" <serue@xxxxxxxxxx> 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 _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers