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