UID/GID identity and filesystems
"User namespaces only solve half the problem", Andy Lutomirski said to start off his session at the 2015 LSFMM Summit. User namespaces remap user IDs (UIDs) and group IDs (GIDs) in the running kernel, but they don't do anything for the UID and GID values stored in filesystems. Those IDs are simply integers stored in the filesystem metadata.
Lutomirski noted that when inserting a USB stick with a "real filesystem, not FAT" on it, the mounted filesystem will have UIDs and GIDs that are likely to be wrong. It would be nice, he said, if instead the files showed up as being owned by the user's UID.
This is also a problem for both NFS and FUSE filesystems, he continued. There is a partial solution in that mounting a FUSE filesystem inside a user namespace will map the UIDs inside the namespace before writing them to the filesystem. NFS has a solution as well. He wondered if there could be a more general approach.
Dave Chinner pointed out that some filesystems have mount options to do simple UID remapping. Those options might simply squash all UID/GIDs on the filesystem into a single UID/GID. An option like that could be added to the virtual filesystem (VFS) layer so that all filesystems had access to it.
That might be a reasonable way to approach the problem, Lutomirski said. Obviously NFS has already solved it, he said, though he had not looked to see what it does. Jeff Layton said that NFS has traditionally mapped UIDs and GIDs between the server and the client. That was originally done using strings for the user and group names, which would get mapped at the other end to integers. The current NFS solution is more complicated, Bruce Fields said, involving LDAP lookups, which is probably not what Lutomirski is looking for.
For his use case, squashing to a single UID would be sufficient, Lutomirski said. Handling Linux Security Module (LSM) contexts is trickier, but that could perhaps be added later. There was some discussion of the different ways that filesystems interpret the uid= and gid= mount options; he would like to see there be some uniformity, which would might require an entirely new mount option (possibly something like vfs_uid=).
[I would like to thank the Linux Foundation for travel support to Boston
for the summit.]
| Index entries for this article | |
|---|---|
| Kernel | Filesystems |
| Conference | Storage, Filesystem, and Memory-Management Summit/2015 |
Posted Mar 26, 2015 1:33 UTC (Thu)
by josh (subscriber, #17465)
[Link] (2 responses)
Ideally, that shouldn't require root intervention to set up; if you have permission to mount, you should be able to set up a map using any UIDs and GIDs you control. Supplementary GIDs give you the latter, and I have a supplementary UIDs patch that would provide the former.
Posted Mar 26, 2015 12:08 UTC (Thu)
by cortana (subscriber, #24596)
[Link] (1 responses)
Posted Mar 26, 2015 15:38 UTC (Thu)
by josh (subscriber, #17465)
[Link]
Posted Mar 26, 2015 23:23 UTC (Thu)
by flussence (guest, #85566)
[Link]
There's already popular prior art in removable media filesystems for storing things in a username-centric way: tar.
The entry price may be a little steep, but for that kind of usability, even I could be convinced to part with 20 or so bytes of my disk.
UID/GID identity and filesystems
UID/GID identity and filesystems
UID/GID identity and filesystems
UID/GID identity and filesystems