Excerpts from Fons Adriaensen's message of 2011-09-29 12:36:30 +0200:
On Thu, Sep 29, 2011 at 11:51:53AM +0200, Tom Gundersen wrote:
What you are seeing is udisks [0]. The policy that is implemented, if I understand correctly, is that udisks allows a user who is physically at the machine to mount the usb drive, but not remote users.
This makes sense for two reasons:
* A user who is physically present could just grab the usb stick and insert it in a laptop where he/she has whatever permissions necessary to do whatever they want, so no security is lost.
This makes no sense. I don't mind if they use their own sticks on their own laptop. I do if they use it one this particular machine.
* Furthermore, you probably don't want have to ask the admin to set up a new entry in fstab for every usb drive that is plugged into your machine.
Not necessary. Priveleges to do certain things are given per user or to groups, it's done when a user's account is set up and that's it. Sudo can handle this nicely. The fstab entries for my own usb disks are there mainly because they have dedicated mount points.
The last thing I want as an admin is a 'parallel administration' such as polkit, in particular if it can grant priveleges just by adding some files to a directory. That's very convenient for package managers etc. but it surely does not enhance security.
A real-world example of 'configuration by adding files': On a debian server, I needed more modules than usual early on, I needed to recreate initramfs with all modules. Debian has a file to configure how many modules are built into initramfs. I changed the config, rebuilt, tested, and it didn't work. Let's say it took me a long while to figure out what was going on. Years ago the debian installer asked my predecessor about the policy for building modules into initramfs, created a file with the config option and put it into a directory somewhere. This file was overriding the main config file and cost me a lot of time. With a system like that you need to dig through lots of files to check whether they could affect a configuration option. Even worse, there could be multiple files affecting the same option, creating a precedence chain that could be a lot of fun to figure out. In my opinion, in this particular case, it would have been way smarter to drop the installing sysadmin into a text editor with the well-commented main config file. Nothing lost, except a lot of frustration years later. Configuration by adding files can create a jungle that's really hard to see through, which can easily lead to miss-configuration. That the whole thing is basically strap-on security in addition to the already built-in security configuration of the system doesn't make it any better.