User and group mount options for ext filesystems
When transporting files between systems using USB sticks or other removable media, one can run into an annoying problem: the UIDs or GIDs of the files on the media don't match those on the system. In most situations, those kinds of devices have a VFAT filesystem that avoids the problem entirely by not storing UID/GID information. But if a user wants to use a "real" filesystem on the device, one of the ext* family for example, it might be useful to specify the local owner of the files. Ludwig Nussel's patch set would do just that for ext2, ext3, and ext4 filesystems.
The patch comes from some work Nussel did "years ago
", he
said, when re-introducing it. It simply
adds two new mount options for ext filesystems. Following in the footsteps
of the VFAT filesystem, the patch would add uid= and gid=
options that would treat all files in the filesystem as being owned by that
UID/GID combination.
When a filesystem is mounted using these options, files retain their
ownership on disk, but they
appear to be owned by the specified user and group. Existing files cannot
have their ownership changed, but new files will be created with the user
and group given at mount time. If a different UID/GID combination is
desired for new files—to match the UID/GID on the device for
example—they can be added to the mount option:
uid=m:n
gid=x:y
which would make the files appear to be owned by m.x and would create new
files as n.y.
One of the first questions to greet Nussel's patch was about putting the code into specific filesystems, rather than the VFS layer. While the VFS seems like the right place, Ted Ts'o points out that there is no easy way to do it all there:
So the question at this point is whether it's cleaner to have the functionality split between the VFS and the file system layers (i.e., with the options parsing and storing the override uid/gid values in the super_block structure) or keeping it all in the file system layer, and accepting the duplication of code across multiple file systems.
Ts'o leaned toward the first approach in that message, but later reluctantly accepted the code duplication. From what he could see, there wasn't enough of a win to put it into the VFS.
There was a little more discussion when Nussel resent the patch on May 10. First off, Jan Kara and Ts'o both wanted to see the patch split into three parts (one for each of ext2, 3, and 4), which Nussel did and posted the next day. But, Roland Eggner and Boaz Harrosh were both concerned about the underlying idea of the patch. Circumventing the access restrictions on the files via a mount option is not a sensible way to address what is, really, an administrative problem, they said.
Eggner described how he "solves" the problem
for systems he administers by essentially creating and using a static list
of UIDs and GIDs. His position is: "If UIDs differ on machines
FORESEEN for file exchange, this is an
administrator error, not a kernel deficit.
" Furthermore,
exchanging files with unexpected systems requires root privileges, he said,
so there
is no need for the mount option override.
Like Eggner, Harrosh is concerned about
security issues with the proposed change. He also doesn't see anything
particularly special about the ext filesystems in terms of removable media,
noting that VFAT is the dominant choice. Beyond that, he questions the
definition of "removable media", and notes that the problem is common in
the NFS world: "we constantly encounter multiple domain
uid/gid views, and it does not mean we blow a hole in POSIX security
rules.
"
But Neil Brown sees things a little differently. He notes that VFAT suffers from limitations including a 4G file size limit and an inability to handle some special characters in file names. That aside, when someone has physical access to a device, it is essentially "removable" in some sense, so that someone may want to easily access the data:
When users insert a VFAT-formatted USB stick or disk, suitably configured systems will give full access to the user by using the VFAT uid/gid options. Nussel's patches essentially just give that same power for ext-formatted devices. While it could certainly lead to problems, those problems are already latent, as Brown pointed out:
While Harrosh is concerned that automounters will start using the options, Brown believes that makes sense for removable devices. In the patch, Nussel mentions that it could be done statically in /etc/fstab or be handled dynamically through udev rules. The alternative suggested by Harrosh is that root can mount the device and then chmod (or chown, presumably) the files appropriately. That seems like a pointless exercise that will just have to be repeated, potentially every time the device is plugged into a new system. Eggner's method is certainly workable, at some level, but makes things more difficult and less "user friendly", Brown said.
In the end, it is a convenience feature. Anyone with physical access to a unencrypted removable device already has the tools available to read the data on it or to put malware onto it. It's a little hard to see how making it easier for legitimate owners of removable USB storage to access their data somehow opens the floodgates for attackers of various sorts. Those of a malicious bent can find any number of ways (live CD, their own Linux system, ...) to access the device as root if they wish.
It is unclear how prevalent ext-formatted removable devices are, so there may be an argument against adding the feature on those grounds. On the other hand, making the ext family work better may encourage people to use those filesystems more often for removable media. The patches do duplicate code in the three separate filesystems, but the total number of lines is changed is only around 100 lines for each. Moving some of that into the VFS (like parsing the mount options and storing the flags in the superblock) might reduce that a bit, but it's not much code overall. Administrators who are worried about the feature will be able to avoid it entirely, though they may need to keep an eye on their distribution's udev rules. Given that it brings the same convenience as VFAT to ext-formatted devices, it seems like a feature worth having.
| Index entries for this article | |
|---|---|
| Kernel | Filesystems/Mounting |
Posted May 17, 2012 2:19 UTC (Thu)
by martinfick (subscriber, #4455)
[Link] (23 responses)
Picture a data serving daemon which runs as a non root user and which needs read/write access to an entire volume of data. It is not uncommon to place this data on a single partition for ease of management. All the files and directories on this partition need the same simple access policy and would be greatly served by the simple uid and gid options suggested in this article. Any other ownership of any data on this partition is inherently an admin mistake and serves no other purpose than to be POSIX compliant. Without such a mount option, it is only a matter of time until a mistake bites the service (an admin mistakingly copies a file as root, the service can not write to this new file...).
How many admins have cron jobs which scan an entire directory tree to verify that every object is porperly owned to combat (poorly) exactly this? Such cron hacks should be easily eliminated entirely with this patch, please apply it right away! :) Backport it even to every kernel in every distro still used in production!
Posted May 17, 2012 5:53 UTC (Thu)
by ringerc (subscriber, #3071)
[Link] (22 responses)
I want to be able to say "Absolutely all files within this tree must always have the permissions <x>, don't make me waste my time with badly behaved programs that set stupid umasks, idiotic network access clients, etc. Just MAKE IT SO."
The only issue I see with this patch is that it's done at the file system level, and IMO this is something that'd be useful for subtrees within a file system too.
I hate to say it, but what I want is to turn off UNIX-style permissions for some directory trees and have Windows-style inherited ACLs instead. Right now I can have the ACLs, but the permissions triplets always take priority, so some stupid @#$#@W app that sets mode 0700 every directory it creates (I'm looking at you, Thunderbird) still breaks access for everyone else. What I want is for the FS to completely ignore permissions within those trees or force them to a specified value on file/directory creation.
Posted May 18, 2012 15:00 UTC (Fri)
by jackb (guest, #41909)
[Link]
Posted Jun 3, 2012 6:03 UTC (Sun)
by quotemstr (subscriber, #45331)
[Link] (20 responses)
Also, Windows supports hard links. Imagine that instead of moving foo/bar.txt to qux/bar.txt, we added qux/bar.txt as a hard link. Which inherited ACL does bar.txt have? It turns out that whichever parent directory modifies its ACL last, wins. (This flaw applies to all ACL inheritance schemes.)
Honestly, I prefer old-fashioned Unix permissions to ACL inheritance. Permissions bits are a lot less confusing and combined with path traversal checking (i.e., in order to read foo/bar.txt, you need execute permission on foo and read permission on bar.txt), it's actually rather flexible.
Posted Jun 4, 2012 4:40 UTC (Mon)
by raven667 (subscriber, #5198)
[Link] (19 responses)
Posted Jun 4, 2012 5:09 UTC (Mon)
by dlang (guest, #313)
[Link]
the fact that more people use windows ACLs is because more people use windows due to the apps that it supports, not because they prefer the ACL model.
Posted Jun 4, 2012 13:16 UTC (Mon)
by nix (subscriber, #2304)
[Link] (4 responses)
Thus, you cannot look at the limited set of ACLs attached directly to files and their inherited permission set to figure out what their actual ACLs are: you have to look at the whole, huge, set for every single file, because the inheritance is a thin layer atop that implementation, and the underlying layer shows through (though that it shows through on non-GUI file moves is particularly shoddy).
Posted Jun 4, 2012 13:33 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
Windows ACLs are a PITA - they're so complicated that one needs a PhD in aclology too understand them completely. But they actually allow several very useful use-cases that depend on ACL inheritance.
In general, I like Unix permission bits for static structures (like /usr or /var filesystems) but I absolutely hate them for shared dynamic directories.
Posted Jun 4, 2012 18:12 UTC (Mon)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Jun 4, 2012 18:42 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Jun 6, 2012 17:33 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Jun 4, 2012 23:43 UTC (Mon)
by quotemstr (subscriber, #45331)
[Link] (12 responses)
Posted Jun 5, 2012 0:29 UTC (Tue)
by nybble41 (subscriber, #55106)
[Link] (11 responses)
That would certainly simplify the ACL inheritance situation, but it's the files themselves you want to control access to, not the directory entries. Having different permissions depending on how you access the file seems like a big step backward to me.
"Live" inherited ACLs have obvious issues; the hard-link case is particularly bad. However, "static" inheritance, as with the default POSIX ACL associated with a directory, offers a reasonable compromise. A file receives the default ACL of the directory in which it is created, and retains that ACL (unless separately modified) even if the file is moved or hard-linked into another directory. If inheritance is preferred after a move or directory permission change, the default ACL of the new containing directory can be re-applied as a separate step.
Posted Jun 5, 2012 1:47 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (10 responses)
And it's not quite unlike the current situation - you must have +r access to file's directory to be able to read it (if you obtain the file handle to it by doing path traversal).
Posted Jun 5, 2012 15:30 UTC (Tue)
by nybble41 (subscriber, #55106)
[Link] (9 responses)
The current situation is that you need read permission to a directory to read its directory entries (e.g. with ls), and search (+x) permission to access files and directories under it. The two are orthogonal; you don't need read access just to traverse a directory, and you don't need search permission just to list the contents.
You also need read access to the individual file to access the file's contents, and typically _that_ is what you want to protect. The read and search bits on the directory govern access to the directory (listing and traversing), while the permission bits on the file govern access to the file's contents.
In the common case of one directory entry per file, there is no difference between your proposal and the way the system already works. Each file would still have one set of permissions, just stored in the directory entry rather than the inode. However, in the case of a file hard-linked into multiple directories, a single item (the contents of the file) would have multiple, possibly conflicting, permissions, depending on the directory entry used to access it. I consider that a step backward from the current model of one clear-cut set of permissions per filesystem object.
Posted Jun 5, 2012 17:11 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (8 responses)
Personally, I'd simply ban hardlinks completely if it was up to me.
Posted Jun 5, 2012 18:40 UTC (Tue)
by nybble41 (subscriber, #55106)
[Link] (7 responses)
That goes double for the idea of banning hard links, which are actually quite useful and logical given the separation between human-readable names and inodes. In any case, without hard links there is no motive for moving the permission bits to the directory entry, as you suggest, since the mapping between directory entries and inodes would be one-to-one. Only the case with hard-links is interesting in this context.
The filesystem permissions apply to inodes and not directory entries for a reason, and once you replace the limited owner/group/other model with POSIX ACLs, the system works rather well as-is. It's only the Windows-style permission model which has issues relating to inherited ACL.
Posted Jun 5, 2012 20:41 UTC (Tue)
by dgm (subscriber, #49227)
[Link] (6 responses)
In the case of write access, you only need back-pointers (from inode to directory) like btrfs has to trivially get "_all_ the directory entries referring to that file".
Posted Jun 5, 2012 21:24 UTC (Tue)
by nybble41 (subscriber, #55106)
[Link] (5 responses)
You'd still need write access to all those directories to change the permissions stored in the directory entries. That can be a problem if you own the file, but someone else owns some or all of those directories. Alternatively, the system could grant write access to directory entries based on the ownership of the target inode rather than the ownership of the directory. Both methods are counter-intuitive.
Regular POSIX ACLs can already express the union of two sets of permissions. There is no need to vary the permissions based on the path used to access the file.
Posted Jun 5, 2012 21:52 UTC (Tue)
by dgm (subscriber, #49227)
[Link] (4 responses)
If you have write permissions, you can wipe the file contents clean and destroy your links. Others will still be able to open the file, but the data would not be there anymore. If you have read permissions, then all you can do is remove your link.
Posted Jun 6, 2012 0:48 UTC (Wed)
by nybble41 (subscriber, #55106)
[Link] (3 responses)
Obviously not. I'm not concerned with copies, just the original, mutable file. If the file is static then the only function of hard links is to save space. As you say, each user might as well have their own copy of the file, and I wouldn't expect to be able to control that copy after granting access.
> If you have write permissions, you can wipe the file contents clean and destroy your links. Others will still be able to open the file, but the data would not be there anymore.
If the contents of the file are dynamic rather than static, then destroying the links removes not just write access, but also read-only access to any future updates. Let's say that there is a file which I own, and which I'm sharing with several other users. Some of these users should be able to write to the file, while others only get read access. For whatever reason (perhaps they're using chroots for sandboxing), some or all of the users have their own hard links to this file rather than using a single path.
With per-inode permissions, to revoke another user's write access while leaving them read access to the shared file, including any future updates, all I have to do is update the ACL on the file. If I were to destroy my link and start over, on the other hand, I would also have to recreate everyone else's links using the new permissions so that we are once again sharing the same file.
Frankly, I don't see any benefits to this change. One ACL per filesystem object has served us well for a long time. The original problem in this thread was with inherited ACLs and multiple parent directories, a problem with doesn't apply to POSIX ACLs, which have defaults but not inheritance. What issue are you trying to solve by moving permissions to the directory entry?
Posted Jun 6, 2012 9:32 UTC (Wed)
by dgm (subscriber, #49227)
[Link] (2 responses)
Basically the same ACLs solve, but using just permission bits. I personally find them much more sensible, and think this is something that could have been better, had Unix been designed this way instead.
Now it's too late, of course.
Posted Jun 6, 2012 15:16 UTC (Wed)
by nybble41 (subscriber, #55106)
[Link] (1 responses)
But POSIX ACLs are basically permission bits, just without the "one user plus one group" limitation. They still govern read, write, and execute/search permissions for specific users and groups and "others". I don't see how requiring multiple directory entries for the same effect is a "more sensible" solution.
That the UNIX permissions model could have been better--I have no argument with you there. We could have used POSIX-style ACLs from the beginning, and skipped the restrictive user/group/other model entirely.
Posted Jun 6, 2012 17:29 UTC (Wed)
by dgm (subscriber, #49227)
[Link]
One word explanation: ls
Multiple word explanation: It's a question of simplicity, I suppose. This way you avoid introducing more concepts and tools. Notice just how simple it is to say "every link can have different permissions". Compare that to the simplest explanation of POSIX ACLs.
Additionally, you don't need to modify existing tools, and hardly add any new ones. The only one you may want to add is something that gives back the list of aliases (links) to a file.
In return for that simplicity you have to give up on the expectation of absolute ownership. You no longer can revoke permissions on other's links, but you can always recreate a file.
Posted May 17, 2012 2:20 UTC (Thu)
by pabs (subscriber, #43278)
[Link] (1 responses)
Posted May 17, 2012 9:17 UTC (Thu)
by zuki (subscriber, #41808)
[Link]
Posted May 17, 2012 4:46 UTC (Thu)
by imunsie (guest, #68550)
[Link] (12 responses)
For instance, I may backup a filesystem to a removable drive, in which case I definitely don't want any automounter deciding to remap UIDs & GIDs at any point just because the drive happens to be removable, whether when performing the backup, or later when reading it because an important part of the backup (the ownership & permissions) could be corrupted.
On the other hand, I am tired of always telling people they need to 'sudo chown -R user.group some_dir' whenever they are copying something to/from my external hard drive and the permissions aren't liberal enough. A related use case is a machine used without root access that is still able to mount removable media (I'm specifically thinking of the machines in the IT labs at uni), where 'sudo chown/chmod' is not possible.
Posted May 17, 2012 6:00 UTC (Thu)
by ringerc (subscriber, #3071)
[Link] (7 responses)
I want it to be a directory xattr, so I can set it for arbitrary sub-trees of a file system. Not just a uid= and gid=, but most importantly a dirmode= and filemode= .
I waste SO MUCH TIME fighting the stupidity of the UNIX permissions model, which presumes every user (a) knows and (b) cares about the permissions of each file and can be trusted to set them. It also assumes that a particular umask is appropriate globally across a session, where in reality different masks are appropriate when working in different data storage spaces. It also causes endless problems with idiotic apps like Thunderbird that like to override the admin-set umask when creating files or directories, leaving files/dirs in shared working areas that only the creator can access.
I want to be able to turn all this crap off. Seriously. Let me say "Everything under /srv/users/editorial is mode 770 (dir) or 660 (file) with group 'editorial'". POSIX ACLs would work if only I could turn off or override UNIX permissions.
As it is, I have the usual horrid cron job. I'm always patching apps when some idiotic application developer gets it into their head to "improve security" by adding an explicit umask() call they don't understand. Again.
This is particularly painful when there's a combination of clients using network file servers (Samba, NetATalk, etc) and clients using local or NFS access.
Posted May 17, 2012 14:21 UTC (Thu)
by scripter (subscriber, #2654)
[Link]
Why? I've got a directory tree full of 10+ years of images that I serve up through apache. It's a nightmare to make sure everything has the correct dirmode, filemode, and SELinux attributes.
Posted May 17, 2012 17:47 UTC (Thu)
by RobSeace (subscriber, #4435)
[Link] (4 responses)
Well, you can get the group inheritence already by just setting the setgid bit on the directory... Maybe we need to allow for similar user inheritence via the setuid bit? Not sure about how to do the modes, though...
Posted May 18, 2012 16:33 UTC (Fri)
by jschrod (subscriber, #1646)
[Link] (1 responses)
> Well, you can get the group inheritence already by just setting the
How do you enforce a gid change when a file is mv'ed into that directory? setgid only works for newly created files.
Posted May 18, 2012 16:59 UTC (Fri)
by RobSeace (subscriber, #4435)
[Link]
Posted May 21, 2012 1:13 UTC (Mon)
by ringerc (subscriber, #3071)
[Link] (1 responses)
As others have noted, it has no effect on moved files or directories, so you land up with subtrees with different permissions that're incorrect for that working group.
More importantly, it doesn't affect the permissions bits. What I really need is to be able to force the group permissions bits to a fixed mode whenever a file is created in or moved into a directory *or* *any* *sub* *directory*. That mode may be g=rwX if I want to use inherited POSIX ACLs instead.
The fact that these issues cause such hassle that I was considering mounting local directories via samba and CIFS (so I could use Samba to remap all permissions) should tell you something!
In truth, I hate to say what I've done in the end is replace our Samba server with a Win2k8 box, and have the Linux boxes mount its storage over CIFS. All these pain points just go away, to the point where I think Windows is currently a much better file server for Linux boxes than Linux its self is at least for some workloads. For one thing, I have volume shadow copy snapshots now, which are so massively better than LVM snapshots that it's hard to believe.
I did this partly because Samba isn't usable as a primary domain controller for Windows 7 machines; our Samba PDC had to go anyway. I was reluctant to do it initially, but after my experience with win2k8 I'm going to be very reluctant to go back to Linux and Samba file servers again. Not unless LVM snapshot expiry stops sucking and preventing the machine from booting, LVM learns to co-operate with the file system(s) on top of it for snapshot management, permissions management for shared access modes stops being so horrible, and of course Samba 4 eventually hits release.
Note that I'm not demanding that any of these things magically happen or whining that they aren't happening. I'm not doing the work to make it so, so I have no right to. Doesn't mean I won't use whatever's best for the job right now.
(Of course, now I'm trying to resist being saddled with Microsoft Exchange. I don't want to give up Cyrus IMAPd and Postfix, but pressure for a working shared calendar and address book is growing within the organisation, and there isn't much out there...)
Posted May 31, 2012 16:38 UTC (Thu)
by nye (subscriber, #51576)
[Link]
Unless you have a powerful technical or ideological objection, I would seriously recommend taking a good, hard look at Solaris.
I've only been trialling Openindiana for a couple of weeks, so it's certainly possible that there are major headaches to come, but so far it has been an incomparably better experience than using Linux + Samba - so much so that I deeply regret wasting my life on the latter for so long.
Posted May 23, 2012 22:35 UTC (Wed)
by dashesy (guest, #74652)
[Link]
Posted May 17, 2012 11:17 UTC (Thu)
by epa (subscriber, #39769)
[Link] (2 responses)
By the same argument, it makes no sense to restrict the 'shutdown' operation for locally logged in users. You may prompt the user 'are you sure?' but in the end you have to grant shutdown permission to somebody who is sitting at the local console, since they have the power switch at their fingertips anyway.
A lot of security measures which are reasonable for a computer locked in an air-conditioned server room make no sense for desktop and portable devices, if you can establish that the user is physically present. If they're logged in remotely then of course you re-enable all those restrictions.
Posted May 17, 2012 18:49 UTC (Thu)
by NRArnot (subscriber, #3033)
[Link]
Or the systems I was using this afternoon in a library. Just a hinged cover glued over those buttons, cable-tied shut. A Mollyguard. (Molly, age 5, thinks to herself "what does that button do if I press it"? )
Posted May 18, 2012 1:57 UTC (Fri)
by imunsie (guest, #68550)
[Link]
You clearly missed the tune2fs mention in my post. I'm not suggesting that you don't have control of your disk, I'm suggesting that I don't want an automounter deciding to ignore permissions if I actually want or need them.
> Some permission bit set by whoever created the filesystem has nothing to do with it, unless you believe in creating some trivially breakable DRM.
Absolutely not, it's about preventing an automounter deciding not to respect file permissions on a volume where they are in fact required (e.g. a backup medium) and inadvertently corrupting the data stored there (permissions are data, and critical to the integrity of backups encompassing multiple users, such as a full backup of ANY Linux system, including "single human user" systems, which still have root, user, www-data, shadow, lp, daemon, etc. users/groups). Same goes for a disk you have pulled out of another system and placed in a USB caddy.
Besides which, if it's a filesystem attribute than it can just as easily be applied to a non-removable media if permissions are not desired there. I can't think of a good solid example of why you would want this (other than Linux failing to detect the media as removable, which has happened to me on a number of occasions), but I'm sure someone else can.
We could even make mke2fs default to disabling permissions on newly created filesystems on removable media, though you wouldn't want that if the removable disk was in a caddy and you were about to debootstrap it. The point is that if you decide the filesystem should support permissions you don't want an automounter ignoring that decision without asking just because the drive happens to be in a caddy. If you later want to disable permissions, that's fine, but it's YOUR choice, not the choice of an automounter.
> If Linux doesn't let you have unrestricted access to a disk you pick up and insert (or a USB stick you plug in), then users will just put the disk into another system which is less choosy.
I presume you mean a system they have root on or are a member of the disk group so they can run tune2fs to set the noperms attribute. Nothing wrong with that, that's THEIR decision.
> By the same argument, it makes no sense to restrict the 'shutdown' operation for locally logged in users. You may prompt the user 'are you sure?' but in the end you have to grant shutdown permission to somebody who is sitting at the local console, since they have the power switch at their fingertips anyway.
As NRArnot stated, that is a bad example because that is an administrative decision to allow local users to shut down. It makes sense in the general case, which is why most sane distributions default to that, but there are special cases where that does not make sense.
> A lot of security measures which are reasonable for a computer locked in an air-conditioned server room make no sense for desktop and portable devices, if you can establish that the user is physically present. If they're logged in remotely then of course you re-enable all those restrictions.
Sure, but that is ALWAYS an administrative decision. We CAN and DO set sane defaults to support that, which is why your Ubuntu system has something installed called "PolicyKit" (IIRC).
Posted May 17, 2012 19:33 UTC (Thu)
by kh (guest, #19413)
[Link]
Posted May 17, 2012 4:48 UTC (Thu)
by pr1268 (guest, #24648)
[Link] (3 responses)
I'm confused—why the colon notation in m:x and n:y (dot notation in the article text)? Are there two separate values, one each for m and x (and n and y)? Assuming one value is a UID (or GID), what's the second value for?
Posted May 17, 2012 6:00 UTC (Thu)
by geofft (subscriber, #59789)
[Link] (1 responses)
"which would make the files appear to be owned by m.x and would create new files as n.y."
The usefulness of this makes is more obvious when you realize that m and x are user-visible uids/gids, and n and y are on-disk uids/gids -- different namespaces entirely. That is, if user geofft on my current system is uid 1001, and I'm mounting my laptop's root partition where user geofft is 1000, then I should mount with uid=1001:1000 so that everything appears owned by me now, but also so that anything new remains owned by me when I put the disk back into my laptop. 1001 is from the host's /etc/passwd, 1000 from the target's.
Posted May 17, 2012 9:20 UTC (Thu)
by pr1268 (guest, #24648)
[Link]
Thanks for the reply. Of course, knowing myself, if I were to use such an implementation, I'd certainly get the m and the x backwards and really mess things up! :-)
Posted May 17, 2012 18:22 UTC (Thu)
by knobunc (guest, #4678)
[Link]
For the stated use case, it makes sense, but it would be nice to be able to pull a disk from another machine (in a different uid scheme) and be able to mount it to back-up onto another machine, and provide a mapping for all user ids present on the disk.
Posted May 17, 2012 6:16 UTC (Thu)
by geofft (subscriber, #59789)
[Link]
As might be implied by the CLONE_NEWFOO name, the primary use case of this is containers -- uid x in one container should have no relationship with uid x in another. (Within a user namespace, an unprivileged user can chroot since setuid binaries cause you to switch to that uid inside the namespace, not outside, etc. so the usual reasons not to let an unprivileged user chroot don't apply. The goal of user namespaces is essentially to let unprivileged users start their own containers.)
But there are a ton of applications for this, when it becomes useful, and one good one seems to be to associate a mount with a namespace. If I plug in an ext2-formatted external drive, I should be able to bind its uids/gids to a namespace I control, instead of to the root-level uid/gid namespace, and thereby be able to su to any user account inside it (and still have POSIX permissions be respected within that namespace). This certainly seems to help with the common case of USB sticks, since I can say that e.g. user 1000 in the root namespace maps to user 0 or 501 or whatever in the namespace associated with the mount, and then be able to directly read and write files and have things work as expected. It also has some benefits for other use cases, like being able to mount a device a container-owner controls a container and have permissions work properly there without impacting the host system.
Posted May 17, 2012 12:45 UTC (Thu)
by mcisely (guest, #2860)
[Link]
JFS has had this user/group settable mount feature for years already. It is in fact why I currently favor using JFS for removable media - vfat is simply not up to the task due to file size limits, screwy case insensitivity, limited character set for file names, etc. The need & rationale for this for use with removable media as described in the article and multiple comments is spot-on. It is long past due for the ext* family of file systems to gain this ability.
Posted May 17, 2012 16:02 UTC (Thu)
by wookey (guest, #5501)
[Link]
I've suffered from the wrong UID/GID thing for many years, mostly over NFS (And I liked the way that the non-kernel NFS server let you supply UID map). Just last week I found that all my backup files for a server that just died have the wrong UIDs (that'll be the new admin doing it wrong, but the point is that it's common) Anything that helps work round this is good IMHO.
Posted May 18, 2012 14:43 UTC (Fri)
by vivo (subscriber, #48315)
[Link]
as root:
# mkdir /g/distfiles
however I would really love to see the feature of userid swapping applyable to bind mounts.
Posted May 22, 2012 10:36 UTC (Tue)
by Jonno (subscriber, #49613)
[Link] (1 responses)
On those drives, permission bits are just a bother. For now I simply do chown and chmod recursively every time I mount on Linux, but this feature would make things much simpler.
Posted May 31, 2012 16:45 UTC (Thu)
by nye (subscriber, #51576)
[Link]
I haven't used ext2fsd in *years*, and back then it had a tendency to cause a BSoD not infrequently, but what problems have you had with ntfs3g? I've always found it to be utterly dependable, and pretty fast besides.
Posted May 24, 2012 15:15 UTC (Thu)
by kraftcheck (guest, #35072)
[Link]
Posted May 30, 2012 20:26 UTC (Wed)
by switzel (guest, #84885)
[Link]
This patch is even more useful for data servers than for removable media!
Doesn't go far enough for file servers
Doesn't go far enough for file servers
I strongly agree with this. I have volumes on my file servers where I very strongly wish I could disable POSIX permissions entirely, replacing them with an inherited ACL from a file system root or subdirectory root.
I want to be able to say "Absolutely all files within this tree must always have the permissions <x>, don't make me waste my time with badly behaved programs that set stupid umasks, idiotic network access clients, etc. Just MAKE IT SO."
I believe the only way to get what you want is to use Samba and CIFS. It can't be done with local filesystems or NFS.
Doesn't go far enough for file servers
Doesn't go far enough for file servers
Doesn't go far enough for file servers
Doesn't go far enough for file servers
Doesn't go far enough for file servers
Doesn't go far enough for file servers
You just need to know parent directory's ACL and file's ACL. No need for anything more significant.
As I pointed out, for Windows ACLs, that is not true: you need to know the mv history of the file and (since files might have been moved out of and then back into directories with inherited ACLs) the ACL history of all directories it has moved into over its lifetime as well. None of this information is recorded anywhere.
Doesn't go far enough for file servers
Doesn't go far enough for file servers
Doesn't go far enough for file servers
Doesn't go far enough for file servers
Doesn't go far enough for file servers
Why? It's totally natural and logical.
Doesn't go far enough for file servers
Doesn't go far enough for file servers
Why is it bad?
Doesn't go far enough for file servers
Doesn't go far enough for file servers
Doesn't go far enough for file servers
Doesn't go far enough for file servers
Doesn't go far enough for file servers
Doesn't go far enough for file servers
Doesn't go far enough for file servers
Doesn't go far enough for file servers
User and group mount options for ext filesystems
User and group mount options for ext filesystems
User and group mount options for ext filesystems
User and group mount options for ext filesystems
User and group mount options for ext filesystems vs xattr for entire subtree
User and group mount options for ext filesystems
User and group mount options for ext filesystems
> > 660 (file) with group 'editorial'".
> setgid bit on the directory...
User and group mount options for ext filesystems
User and group mount options for ext filesystems
User and group mount options for ext filesystems
User and group mount options for ext filesystems
User and group mount options for ext filesystems
Bad example
User and group mount options for ext filesystems
Magic UID
User and group mount options for ext filesystems
User and group mount options for ext filesystems
User and group mount options for ext filesystems
User and group mount options for ext filesystems
It seems like this might fit in well with CLONE_NEWUSER / user namespaces, which allows an unprivileged user to set up a process (and its descendants) to have uids/gids completely separate from the uid/gids of the host, such that e.g. uid 0 in the namespace has none of the permissions that root has on the host machine. There's current work to set up a mapping between inner uids/gids and outer ones, so that a user can be assigned (by the sysadmin) a handful of unprivileged users, and map one of them to uid 0 inside the namespace and freely setuid() to other ones that they're allowed.Relationship with CLONE_NEWUSER?
JFS already has this
User and group mount options for ext filesystems
User and group mount options for ext filesystems
# chown portage:portage /g/distfiles
# chmod 6775 /g/distfiles
# touch /g/distfiles/pippo
# ls -l /g/distfiles/pippo
-rw-r--r-- 1 root portage 0 May 18 16:40 /g/distfiles/pippo
User and group mount options for ext filesystems
User and group mount options for ext filesystems
User and group mount options for ext filesystems
User and group mount options for ext filesystems
With vfat this was not a problem but of course it has the described shortcomings (most importantly the 4GB bound). So ideally I would like a filesystem "like vfat" with these shortcomings removed (I somehow think that a "light" filesystem is appropriate for removable drives).
In that spirit I also support the idea of an option to ext2 to "turn off" permissions. But really I am happy about any solution at all.