User and group mount options for ext filesystems [LWN.net]

User and group mount options for ext filesystems

Posted May 17, 2012 4:46 UTC (Thu) by imunsie (subscriber, #68550)
Parent article: User and group mount options for ext filesystems

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.

(Log in to post comments)

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
> setgid bit on the directory...

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.

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).