Filesystems Mount OSX – How to Prevent FS from Unmounting

It's both a historical and security restriction.

Historically, most drives weren't removable. So it made sense to restrict mounting to people who had legitimate physical access, and they would likely have access to the root account. The fstab entries allow administrators to delegate mounting to other users for removable drives.

From a security point of view, there are three major problems with allowing arbitrary users to mount arbitrary block devices or filesystem images at arbitrary locations.

• Mounting to a non-owned location shadows the files at that location. For example: mount a filesystem of your choice on /etc, with an /etc/shadow containing a root password that you know. This is fixed by allowing a user to mount a filesystem only on a directory that he owns.
• Filesystem drivers have often not been tested as thoroughly with malformed filesystem. A buggy filesystem driver could allow a user supplying a malformed filesystem to inject code into the kernel.
• Mounting a filesystem can allow the mounter to cause some files to appear that he would not otherwise have permission to create. Setuid executable and device files are the most obvious examples, and they are fixed by the nosuid and nodev options which are implied by having user in /etc/fstab.
  So far enforcing user when mount is not called by root is enough. But more generally being able to create a file owned by another user is problematic: the content of that file risks being attributed by the purported owner instead of the mounter. A casual attribute-preserving copy by root to a different filesystem would produce a file owned by the declared-but-uninvolved owner. Some programs check that a request to use a file is legitimate by checking that the file is owned by a particular user, and this would no longer be safe (the program must also check that the directories on the access path are owned by that user; if arbitrary mounting was allowed, they would also have to check that none of these directories are a mount point where the mount was created neither by root nor by the desired user).

For practical purposes, it is possible nowadays to mount a filesystem without being root, through FUSE. FUSE drivers run as the mounting user so there is no risk of privilege escalation by exploiting a bug in kernel code. FUSE filesystems can only expose files that the user has the permission to create, which solves the last issue above.

The problem is that your /etc/mtab is not a file but a symlink to /proc/mounts. This has advantages but also the disadvantage that user does not work. You already guessed right the reason for that: "the system is confused when remembering who mounted the file system". This information is written to mtab, cannot be written there in your case though. The kernel doesn't care (doesn't even know) about user mounts (this is a userspace feature). Thus this info is not contained in /proc/mounts.

Do this:

cd /etc
cp mtab mtab.file
rm mtab
mv mtab.file mtab

umount as user should work after you have mounted the volume again.