Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> "Serge E. Hallyn" <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
https://lists.linux-foundation.org/mailman/listinfo/containers
_______________________________________________
Devel mailing list
[email protected]
https://openvz.org/mailman/listinfo/devel
