https://bugzilla.novell.com/show_bug.cgi?id=293429#c8 Bernhard Kaindl <bk@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Info Provider|bk@novell.com | --- Comment #8 from Bernhard Kaindl <bk@novell.com> 2007-08-20 14:58:24 MST --- The "user" approach does not work for ntfs-3g without the suid bit on the ntfs-3g mount helper like it works for FAT filesystems and for the in-kernel ntfs filesystem because those do not need a mount helper at /sbin/mount.<fstype> The cause of the mis-thought is that this assumption is not always true:
/sbin/mount.ntfs-3g does not need to be setuid root, it is called root:root as helper already.
That is not true when mount is called from a non-root, despite /bin/mount being suid-root. Try this: echo 'main() {printf("uid: %d, euid: %d\n", getuid(), geteuid());}' >uidprint.c gcc uidprint.c -o /sbin/mount.foobar echo 'foormbar /foobar foobar user' >>/etc/fstab su nobody -c 'mount /foobar' output is: uid: 65534, euid: 65534 So it seems that privileges are dropped by mount before calling the mount helpers which only a few filesystems need, e.g. I only have these installed: # ls -1 /sbin/mount.* /sbin/mount.cifs /sbin/mount.fuse /sbin/mount.ncp /sbin/mount.ncpfs /sbin/mount.nfs /sbin/mount.nfs4 /sbin/mount.ntfs-3g The errors which one gets when "user" is specified in fstab for an ntfs-3g fstype are: Error opening partition device: Permission denied Failed to startup volume: Permission denied Failed to mount '/dev/sdc1': Permission denied In the words of Szaka (Szabolcs Szakacsits, member of the ntfs-progs team - he wrote ntfsresize - and author of ntfs-3g), the issue is simple:
FUSE mounting block devices is privileged, suid-root is needed. The privilege is dropped after successful mount, so it's much safer than any file system kernel driver. Security related things could be improved still a lot but quite many things too which are far more important.
I agree with him. One could try to get cooperation from the util-linux maintainers to change /bin/mount to pass the opened file descriptor of the block device to the mount helper, but that isn't a priority for Szaka. If that is important to us, we could see if we could get it done but it would also take some work to get it done and upstream. As the privileges are dropped after successful mount, I do not see many possibilities to attack ntfs-3g. At mount time, ntfs-3g is controlled through a limited set of mount options After mount, the main issue is to use selective file permissions, but Thomas Fehr changed Yast2 to use the proposed fmask and dmask for Beta 2 now. ----------------------------------------------------------------------------- Using Hal with ntfs-config The only other way which I see to give users write access to NTFS partitions is to use hal, but to do this cleanly, hal and KDE would need some changes and it would require some more time to implement and test before would have a clean hal solution which then also supports automatic mounting of ntfs disks. There is a GUI tool, called ntfs-config recommended by Skaka (used by debian and ubuntu so far) which: * has support for instantly mounting of NTFS partitions at program startup: - asks for the mount point for newly connected NTFS volumes on program startup * supports to switch any mounted NTFS volume from read-only to read-write:4 - it does this by switching between ntfs-3g and kernel ntfs * has a wrapper which supports GNOME and KDE's "su" tools to do the mounting and unmounting * writes fstab entries for all NTFS volumes disks which it has seen so far (it adds new disks which are not in /etc/fstab yet on program startup) * shows a check box for using the "force" option when mounting with ntfs-3g fails due to scheduled check and I tested it all to work. * Has translations for many languages But we do not have it as package yet, so we'd have make an exception to the "no new packages" policy which is in force now to use it. ntfs-config is not perfect, e.g. it uses device paths (e.g. /dev/sdc1, which changes randonly when you have multible USB/FireWire disks) instead of the fs UUID, but that could be fixed if we have enough time: BUG: ntfs-config reads, but doesn't write UUID fstab entries yet: https://bugs.launchpad.net/ubuntu/+source/ntfs-config/+bug/121062 To give you an impression of the state of where ntfs-config, I show you the an changelog entry from ntfs-config ( Source: https://bugs.launchpad.net/ntfs-config/+bug/105015 ):
RC4 should close that bug :
* New : device mounted on multiple mount point should now be handle correctly * New : Propose actions when mounting/unmounting fail : - Propose the lazy option when device is busy - Propose to remove bad option or revert them to default when an unknow option was detected - Propose to use default FSTYPE driver when type wasn't found - Propose to use the force option when NTFS is unclean with ntfs-3g * Translation : A bunch of new translations thanks to a bunch of cool guys
============================================================================== While this item is not in the scope of this bug (mounting ntfs) it's a bit related as it's about unmounting with ntfs-3g: ------------------------------------------------------------------------------ Safe volume removal For good handling of external NTFS disks, we should also implement Save disk removal (unmounting thru an icon in the panel) because unlike USB sticks using VFAT, NTFS disk connected thru USB or Firewire should rather be cleanly unmounted before disconnecting them because the filesystem could be left in an unclean state. During testing what happens on unplug/hotplug in different situations (e.g. with open files), I caused my external USB disk to enter the "filesystem check scheduled" state in which ntfs-3g refuses to mount the filesystem unless it's called with the "force" option. I could not test this yet (no Windows install to test it using dual-boot, booting into Linux when Windows is hibernated), but the force option may possibly also force a mount if the NTFS $Logfile indicates that the filesystem is currently in use, e.g. when Windows was put into standby or hibernation. Such volume should better not be written to in any way as that may cause quite bad things to happen when Windows resumes and assumes that the disk has not changed while it was sleeping. Without a windows machine, I'd have to ask Szaka or check the source code to find out what force does then. ------------------------------------------------------------------------------ -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.