Kyle Moffett <[email protected]> writes:
> On Jul 14, 2006, at 10:17:28, Serge E. Hallyn wrote:
>> Quoting Eric W. Biederman ([email protected]):
>>> No. The uids in a filesystem are interpreted in some user namespace
>>> context. We can discover that context at the first mount of the filesystem.
>>> Assuming the uids on a filesystem are the same set of uids your process is
>>> using is just wrong.
>>
>> But, when I insert a usb keychain disk into my laptop, that fs assumes the
>> uids on it's fs are the same as uids on my laptop...
>>
>> Solving that problem is interesting, but may be something to work with a much
>> wider community on. I.e. the cifs and nifs folks. I haven't even googled to
>> see what they say about it.
>
> IMHO filesystems _and_ processes should be primary objects in a UID namespace.
> This would make it possible to solve the usb-key problems _and_ the
> user-mounted FUSE problems. If "ns0" is the boot uid namespace, then put the
> freshly mounted USB key in a new "ns1" (names just for convenience). All the
> user processes would continue to be in ns0, but with the kernel keyring system
> you could create a new "uid" keytype and give the logged in user (ns0,user_uid)
> a user-key with (ns1,0*). If you added bits to the user-keys to represent the
> equivalent of CAP_DAC_OVERRIDE/CAP_CHOWN/etc for that process and UID
> namespace, then the user could do anything to any file on their USB key, even
> change ownership, without disrupting the rest of the system. Likewise, if you
> did that for user FUSE filesystems, then suid binaries would not be able to get
> themselves into trouble in exploitive FUSE infinitely-recursive monstrosities.
Thank you!
It is nice to see when someone else gets the point :)
I had not quite considered how that affects user mounted filesystems
but that does look like a real solution.
Now we just need to implement these things and work out the details of
user keys to map user ids.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
