Weekly Edition
Return to the Kernel page
| |||||||||||||
User and group mount options for ext filesystemsWhen 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:
The problem is that there will need to be at least some
support in the individual file system, since there isn't a good place
for the VFS to intercept the internal file system iget() function to
patch in the override uid/gid values.
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:
[...] if I "own" a filesystem - whether because I hold the
physical non-encrypted devices or because I know the encryption key - then I
want to be able to leverage that "ownership" to full access rights to
the contents of the filesystem. By typing in a key or plugging in a device I
want to get full "root" access to the filesystem on the device. Not giving
that to me is just getting in my way.
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:
You cannot prevent data
destruction on such devices if you lose physical control, and the only
workable data privacy option is encryption. Trying to pretend that file
permission bits mean anything is extremely naive.
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. (Log in to post comments)
This patch is even more useful for data servers than for removable media! Posted May 17, 2012 2:19 UTC (Thu) by martinfick (subscriber, #4455) [Link]
I think that an important use case for such a patch is being completely overlooked. I basically just wrote the same patch and we are considering deploying this patch internally on some of our servers. Such a patch can be very useful from a sysadmin standpoint to prevent many permission related mistakes.
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!
Doesn't go far enough for file servers Posted May 17, 2012 5:53 UTC (Thu) by ringerc (subscriber, #3071) [Link]
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."
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.
Doesn't go far enough for file servers Posted May 18, 2012 15:00 UTC (Fri) by jackb (subscriber, #41909) [Link] 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 Posted Jun 3, 2012 6:03 UTC (Sun) by quotemstr (subscriber, #45331) [Link]
Windows ACLs are a mess too --- they're attached to files (think "inodes"), not directory entries. If you have a file foo/bar.txt and bar.txt has dutifully inherited its ACL from foo on creation, then if you move foo/bar.txt to qux/bar.txt, bar.txt *retains its old ACL*. Some tools, like Explorer, will reset file ACL on move, but this work is done at the UI-tool level, not the OS level.
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.
Doesn't go far enough for file servers Posted Jun 4, 2012 4:40 UTC (Mon) by raven667 (subscriber, #5198) [Link]
I don't think the behavior you described is unreasonable, I'm not sure what "better" behavior would be in that situation. In any event there are far far far more people who prefer ACLs and find them better for practical use than Unix permissions bits for shared file management.
Doesn't go far enough for file servers Posted Jun 4, 2012 5:09 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
please show me any system that allows both unix permissions and ACLs where more people use the ACLs than the unix permissions.
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.
Doesn't go far enough for file servers Posted Jun 4, 2012 13:16 UTC (Mon) by nix (subscriber, #2304) [Link]
The problem with the system quotemstr describes is that it is path-dependent: if you look at the inherited set of ACLs attached to some directory, you cannot use it to determine what the properties of files underneath are likely to be unless you know the history of those files (which is not recorded anywhere). Worse yet, files *outside* that directory may have been affected by its ACL, as long as they were at one point within that directory -- or, rather, they would have been affected by whatever ACL it had at that point (it may have been changed, but the moved-out file's ACL would not have changed).
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).
Doesn't go far enough for file servers Posted Jun 4, 2012 13:33 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
You just need to know parent directory's ACL and file's ACL. No need for anything more significant.
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.
Doesn't go far enough for file servers Posted Jun 4, 2012 18:12 UTC (Mon) by nix (subscriber, #2304) [Link] 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 Posted Jun 4, 2012 18:42 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Why? Moving a file simply changes its ACLs. No need to track them for the whole lifetime of the file.
Doesn't go far enough for file servers Posted Jun 6, 2012 17:33 UTC (Wed) by nix (subscriber, #2304) [Link]
As was pointed out a few posts up, moving a file does *not* change its ACLs unless you do the move *from the GUI*. A command-line move leaves the ACLs unchanged, and does not respect inherited ACLs (i.e. inherited ACLs are not really part of the permission system but are a hack implemented at the GUI level). Thus the problems I mentioned.
Doesn't go far enough for file servers Posted Jun 4, 2012 23:43 UTC (Mon) by quotemstr (subscriber, #45331) [Link]
The right thing to do would have been to attach ACLs to *directory entries*, not to files themselves. When you do that, everything automatically just works.
Doesn't go far enough for file servers Posted Jun 5, 2012 0:29 UTC (Tue) by nybble41 (subscriber, #55106) [Link]
> The right thing to do would have been to attach ACLs to *directory entries*, not to files themselves.
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.
Doesn't go far enough for file servers Posted Jun 5, 2012 1:47 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
>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.
Why? It's totally natural and logical.
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).
Doesn't go far enough for file servers Posted Jun 5, 2012 15:30 UTC (Tue) by nybble41 (subscriber, #55106) [Link]
> 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).
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.
Doesn't go far enough for file servers Posted Jun 5, 2012 17:11 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
>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.
Why is it bad?
Personally, I'd simply ban hardlinks completely if it was up to me.
Doesn't go far enough for file servers Posted Jun 5, 2012 18:40 UTC (Tue) by nybble41 (subscriber, #55106) [Link]
If you can't see why it's a bad idea for both security and usability to have two different, conflicting sets of permissions for the same data, then I can only say that I'm glad you probably don't have any influence on this issue. Consider the case of restricting write access to a file: you would need to know about, and have write access to, _all_ the directory entries referring to that file, as opposed to just a single inode in the current model.
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.
Doesn't go far enough for file servers Posted Jun 5, 2012 20:41 UTC (Tue) by dgm (subscriber, #49227) [Link]
Sometimes it's a GOOD idea to have different sets of permissions. The final permission set is just the union of both, something that can be difficult to express otherwise. It would be possible to create *complimentary* permissions, but not conflicting (they are only conflicting if you think of the bits as restriction flags, not permission flags).
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".
Doesn't go far enough for file servers Posted Jun 5, 2012 21:24 UTC (Tue) by nybble41 (subscriber, #55106) [Link]
> 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".
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.
Doesn't go far enough for file servers Posted Jun 5, 2012 21:52 UTC (Tue) by dgm (subscriber, #49227) [Link]
You don't need write permissions, because what you're describing is not very reasonable. Imagine we are talking about copies of the data. Would you expect to have a magic command to wipe out all copies of "your" data? Well, if you're the RIAA you would, but it would be unreasonable.
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.
Doesn't go far enough for file servers Posted Jun 6, 2012 0:48 UTC (Wed) by nybble41 (subscriber, #55106) [Link]
> You don't need write permissions, because what you're describing is not very reasonable. Imagine we are talking about copies of the data. Would you expect to have a magic command to wipe out all copies of "your" data?
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?
Doesn't go far enough for file servers Posted Jun 6, 2012 9:32 UTC (Wed) by dgm (subscriber, #49227) [Link]
> What issue are you trying to solve by moving permissions to the directory entry?
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.
Doesn't go far enough for file servers Posted Jun 6, 2012 15:16 UTC (Wed) by nybble41 (subscriber, #55106) [Link]
> Basically the same ACLs solve, but using just permission bits.
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.
Doesn't go far enough for file servers Posted Jun 6, 2012 17:29 UTC (Wed) by dgm (subscriber, #49227) [Link]
> I don't see how requiring multiple directory entries for the same effect is a "more sensible" solution.
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.
User and group mount options for ext filesystems Posted May 17, 2012 2:20 UTC (Thu) by pabs (subscriber, #43278) [Link]
Finally! I've been waiting for this for years.
User and group mount options for ext filesystems Posted May 17, 2012 9:17 UTC (Thu) by zuki (subscriber, #41808) [Link]
Yes. I don't really see why we would want FAT to be more feature-full than EXT[234].
User and group mount options for ext filesystems Posted May 17, 2012 4:46 UTC (Thu) by imunsie (subscriber, #68550) [Link]
Wouldn't this be better suited as a filesystem attribute set with something like 'mkfs.ext3 -O noperms' or 'tune2fs -O +noperms'? Then it's up the admin who created the filesystem to decide whether it uses traditional posix permissions or vfat style files are owned by whoever mounted it.
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.
User and group mount options for ext filesystems Posted May 17, 2012 6:00 UTC (Thu) by ringerc (subscriber, #3071) [Link]
I agree, FS attributes would be the right way to go - but I'd go further.
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.
User and group mount options for ext filesystems vs xattr for entire subtree Posted May 17, 2012 14:21 UTC (Thu) by scripter (subscriber, #2654) [Link]
I agree. And the xattr for the entire subtree shouldn't just override uid, gid, dirmode and filemode -- it should override the SELinux attributes as well.
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.
User and group mount options for ext filesystems Posted May 17, 2012 17:47 UTC (Thu) by RobSeace (subscriber, #4435) [Link]
> Let me say "Everything under /srv/users/editorial is mode 770 (dir) or 660 (file) with group 'editorial'".
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...
User and group mount options for ext filesystems Posted May 18, 2012 16:33 UTC (Fri) by jschrod (subscriber, #1646) [Link]
> > Let me say "Everything under /srv/users/editorial is mode 770 (dir) or
> > 660 (file) with group 'editorial'".
> 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.
User and group mount options for ext filesystems Posted May 18, 2012 16:59 UTC (Fri) by RobSeace (subscriber, #4435) [Link]
Hmmm, true enough... I guess I always figured it'd work for mv'd files too, but never tried... Bummer...
User and group mount options for ext filesystems Posted May 21, 2012 1:13 UTC (Mon) by ringerc (subscriber, #3071) [Link]
`chmod g+s` is all well and good as far as it goes, but it doesn't go far.
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...)
User and group mount options for ext filesystems Posted May 31, 2012 16:38 UTC (Thu) by nye (guest, #51576) [Link]
>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.
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.
User and group mount options for ext filesystems Posted May 23, 2012 22:35 UTC (Wed) by dashesy (subscriber, #74652) [Link]
Yes, the directory approach seems like a much better solution. Then depending on where I mount the removable media, permissions can be respected or not. I can mount a backup hard drive to /mnt/backup normally or my USB stick on /mnt/usb to access just everything.
User and group mount options for ext filesystems Posted May 17, 2012 11:17 UTC (Thu) by epa (subscriber, #39769) [Link]
It's up to the person who has the disk in their hand. If I have the disk, it's mine, and I can do what I want with it. Some permission bit set by whoever created the filesystem has nothing to do with it, unless you believe in creating some trivially breakable DRM. 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.
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.
Bad example Posted May 17, 2012 18:49 UTC (Thu) by NRArnot (subscriber, #3033) [Link]
Retricting shutdown is a bad example. There are environments where a local user has no access to the power switch and reset button. For example, a public "kiosk". Vandal-proof keyboard and trackball and display, metal enclosure locked shut and permanently wired into the electricity supply (ie no plug). Inside sits a plain ordinary PC.
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"? )
User and group mount options for ext filesystems Posted May 18, 2012 1:57 UTC (Fri) by imunsie (subscriber, #68550) [Link]
> It's up to the person who has the disk in their hand. If I have the disk, it's mine, and I can do what I want with it.
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).
Magic UID Posted May 17, 2012 19:33 UTC (Thu) by kh (subscriber, #19413) [Link]
I am afraid this is probably terribly naive, but I wonder if it would not be better to have a magic UID - GID that when present, caused the VFS to ignore all permissions. Then the other part would be to create a way to format a disk so that when such a system was mounted, all new files would be created with the magic UID - GID. That way it would take a format action to create such a disk.
User and group mount options for ext filesystems Posted May 17, 2012 4:48 UTC (Thu) by pr1268 (subscriber, #24648) [Link] 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?
User and group mount options for ext filesystems Posted May 17, 2012 6:00 UTC (Thu) by geofft (subscriber, #59789) [Link]
From the next line in the article:
"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.
User and group mount options for ext filesystems Posted May 17, 2012 9:20 UTC (Thu) by pr1268 (subscriber, #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! :-)
User and group mount options for ext filesystems Posted May 17, 2012 18:22 UTC (Thu) by knobunc (subscriber, #4678) [Link]
I was a little surprised that there was no way to do more than one user mapping.
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.
Relationship with CLONE_NEWUSER? Posted May 17, 2012 6:16 UTC (Thu) by geofft (subscriber, #59789) [Link] 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.
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.
JFS already has this Posted May 17, 2012 12:45 UTC (Thu) by mcisely (subscriber, #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. -Mike
User and group mount options for ext filesystems Posted May 17, 2012 16:02 UTC (Thu) by wookey (subscriber, #5501) [Link]
I certainly use ext2/3 formatted removeable media whenever I can - you can run systems off them and preserve UID/mode info - a VFAT rootfs simply doesn't work. I've long resented the way we've been stuck with VFAT (and it's bloody patents to add insult to mediocrity) for so long, not least because of the way USB-storage is implmented (logical block level).
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.
User and group mount options for ext filesystems Posted May 18, 2012 14:43 UTC (Fri) by vivo (subscriber, #48315) [Link]
change group on the fly for a directory is possible like this:
as root:
# mkdir /g/distfiles
however I would really love to see the feature of userid swapping applyable to bind mounts.
User and group mount options for ext filesystems Posted May 22, 2012 10:36 UTC (Tue) by Jonno (subscriber, #49613) [Link]
I use ext3 on removable media simply because vfat is not an option (4 GiB limit), and ext2fsd on Windows works better than ntfs3g on Linux.
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.
User and group mount options for ext filesystems Posted May 31, 2012 16:45 UTC (Thu) by nye (guest, #51576) [Link]
>ext2fsd on Windows works better than ntfs3g on Linux
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.
User and group mount options for ext filesystems Posted May 24, 2012 15:15 UTC (Thu) by kraftcheck (guest, #35072) [Link]
Given that UID/GID data is largely useless and a nuissance for most removable media, why not let the user specify that they do not want UID/GID data for a given file system when the file system is created. Save a value in the superblock indicating a UID/GID-less file system. The permissions can be handled the same as is done for VFAT in that case (controlled by mount options and defaulting to root.) This way a) developers don't need to worry about deciding which device is "removable", the user specifies the behavior they want for the evice and b) any determination of how the device is to be handled is made once when the file system is created rather than every time it is mounted.
User and group mount options for ext filesystems Posted May 30, 2012 20:26 UTC (Wed) by switzel (guest, #84885) [Link]
I am very happy that people are working on this. To those who say, this problem should be circumvented by configuring "the" machine differently I would like to describe my situation: I have usb hard disk on which I store my data to carry them around with me. I use this hard disk on various computers of whose existence I am often not previously aware and on which I certainly have nothing near to root access.
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.
|
|||||||||||||