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) 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 saying. thanks, -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers