Automount options

Bug #880965 reported by Kevin Chadwick
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
udisks (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

The stance on default mount options have changed back from noexec (correct) to exec in bug #87627 for legacy compatibility reasons.

noexec should be the default for writeable areas and then partitions with binary's set exec in fstab. Home partitions are often set noexec to receive downloadable content, the automounter now breaks that feature. This allows some argument of Linux being potentially susceptible to viruses.

There have been other default requests like utf8, which have had to be fixed. These should be easily configurable by root perhaps as optional flags in fstab. Udev is far too modular to be appropriate for this.

We should always maintain configurability atleast by root as we shouldn't expect to know all possible system setups.

Revision history for this message
Martin Pitt (pitti) wrote :

While I'd prefer noexec myself, we tried this several times and got too much pushback. Your home partition is hopefully not on a removable device which isn't even in /etc/fstab (I wouldn't see how that works, as we only automount to /media). So I'm afraid we'll leave the defaults as they are.

Thanks!

affects: udev (Ubuntu) → udisks (Ubuntu)
Changed in udisks (Ubuntu):
status: New → Won't Fix
Revision history for this message
Martin Pitt (pitti) wrote :

Also, we don't mount with "exec" any more, but with "showexec", which should provide a reasonable compromise. I. e. only files named .com, .exe, .bat are executable, no others.

Revision history for this message
Kevin Chadwick (kc-launchpad) wrote :

Let me reiterate a little clearer. For my systems I had a few choices. Disable udev and use sudo or another auto-mounting package. I wrote udev rules with flush and sync as the unmount wasn't working properly and I'm not going to spend time picking through the mess of udev rules etc.. It wasn't a pleasant experience and works but doesn't integrate fully with the file managers etc.. But that's OK for ME.

The real issue for me is as rightly recommended in many unix security books and in proper unix tradition, you should not especially on reasonably secure systems allow write and execute except by hopefully well coded priviledged processes like a package manager to any area of your filesystem. Finally the dismissal of /tmp rightly being mounted noexec is finally regaining traction in the Linux world after many years of wrongful dismissal in the past. This type of security misunderstanding/blazaness may explain to some degree why these defaults have prevailed.

It is easy to mount a home partition exec in fstab for gamers or wine users, In fact most distros force this by default as /home is for ease of install incorrectly situated in root /. It is also easy in more than one way (udev, fstab) and without consequence to specify a particular usb to mount exec. Any pushback that I can see should therefore be dismissed. It is wrong to force extra work on to people who choose to mount /home, /tmp etc. noexec and find udev then breaks this policy by allowing users to introduce programs via usb, intentionally or not in the case of system attacks from unmoniitored usbs or users who download onto usb rather than the home partition, Some organisations disable the usbs at the bios level. Local exploits are rife as kernel.org found out and you may wish or be forced to permit wine execution of pre-determined binaries but not wish execution of user-determined .exes.

The preferable alternative to a default of noexec, which would resolve the countless blogs and recent Arch linux mailing list thread of particular options (sync) for certain filesystems

"http://mailman.archlinux.org/pipermail/arch-general/2011-December/023091.html"

 is to add an ENV or Variable to udev rules preferably picked up from a central config file like fstab that sets the default mount options. The default mount location would also be handy for read-only systems, but of no necessity.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.