https://bugzilla.novell.com/show_bug.cgi?id=293429#c1 --- Comment #1 from Péter Kerékfy <kerekfyp@komal.hu> 2007-07-27 02:34:40 MST --- I have revisited my opinion. You should remove all umask,uid,gid options because they trigger the default_permissions parameter. This parameter enables permission checking on chmod operations and it makes the kernel return 'Operation not permitted' messages to non-root users. You should remove the users parameter too since it makes no sense with a non-setuid ntfs-3g binary. Since most users do not need permission handling on their ntfs filesystems I suggest to use only the 'locale' mount option in fstab (it is essential to access files with national characters in its names). Example fstab line: /dev/sdb1 /windows/C ntfs-3g defaults,locale=en_US.UTF-0 0 0 The locale paramter should be set to the system locale (maybe RC_LANG in /etc/sysconfig/language ??) Regards, Peter. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=293429#c3 Marcus Meissner <meissner@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|ntfs-3g default mount |AUDIT-0: ntfs-3g integration / default mount |options |options --- Comment #3 from Marcus Meissner <meissner@novell.com> 2007-07-30 00:28:44 MST --- i am not sure setuid root is a good idea either. but please already restrict the permissions. (perhaps a solution like for removable disks should be looked for? But I am not sure about that either) -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=293429#c5 --- Comment #5 from Marcus Meissner <meissner@novell.com> 2007-08-14 06:11:49 MST --- do we have a testsetup somewhere? /bin/mount is setuid root already, shouldnt this be sufficient? -- 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.

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.

https://bugzilla.novell.com/show_bug.cgi?id=293429#c10 --- Comment #10 from Ludwig Nussel <lnussel@novell.com> 2007-08-23 06:40:00 MST --- Mounting via hal only works with devices that are not listed in fstab, that's correct. Ie it should work with hotplugged devices because those are not in fstab. Partitions on built in hard disks are not handled by hal due to another reason, some fdi file sets a flag on them that prevents mounting but that hits fat etc as well. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=293429#c12 Bernhard Kaindl <bk@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bk@novell.com Status|NEEDINFO |NEW Info Provider|bk@novell.com | --- Comment #12 from Bernhard Kaindl <bk@novell.com> 2007-09-18 16:04:59 MST --- To sum up: The security team's claim (I refuted it on the top of comment 8)

/sbin/mount.ntfs-3g does not need to be setuid root, it is called root:root as helper already.

is not true. The team's suggestion was based on this, so it does not work. I now also checked the source, it unconditionally does setuid(getuid()); setgid(getgid()); to restore drop the euid+egid and restore normal user uid/gid before calling the mount helper. I have looked at the ntfs-3g code and as Szaka said, it drops privileges after the mount itself completed. Before the euid is dropped, the command line options are parsed and the fuse mount library is called. That library is used by fusermount for the same purpose and and already using suid root: $ grep fuse /etc/permissions* /etc/permissions.easy:/usr/bin/fusermount root:trusted 4755 /etc/permissions.secure:/usr/bin/fusermount root:trusted 4750 /etc/permissions.paranoid:/usr/bin/fusermount root:trusted 0755 So the only code which is not yet used suid root is the command line option parsing in ntfs-3g, which is fairly simple and should be easy to audit. I have not seen any flaw in it so far, but I do not have the responsibility to judge it. ---------------------------------------------------------------------------------- My personal opinion is that as it's currently used, the user approach lacks support for hotplugging, so I think that to do it properly we'd have to use hal. I thought that, ntfs-config, the program which I hoped could make it all "just work" seems to be quite broken in several ways and does not do at all what I hoped: I thought that it would be integrated with hal, but the only thing which it does with hal is that it installs an fdi file in /etc/hal/fdi/policy which changes the fstype of hotpluggable ntfs partitions to ntfs-3g and allows the hal mount users to use the ntfs-3g locale mount option, but that's all. Besides that, it fully depends on root rights, does not mount thru hal but directly with mount and creates fstab entries for the USB and firewire disks which it sees, which locks out users of hal in two ways: * Since the filessystems are not mounted by hal, they cannot be unmounted thru hal * Since they are listed in /etc/fstab, they cannot be mounted thru hal Further observations: * It uses the non-persistent /dev/sd[a-z][number] instead /dev/disk-by-id/{id}, so if you ever connect a different USB or FireWire disk than the one it put into /dev/fstab, things break disks are not identified in any way. * In the medium-size, very diverse test setup with two identical USB disk drives (which which can be only identified by their differing disk-by-id and their different partitions), one FireWire disk and two more USB disks, it seems to add all partitions to /etc/fstab, but mounts only 2 of them and while I shows even 4 partitions in the second run, it still does nothing when (un)checking the read-write checkboxes for the other two partitions. * It already takes a quite few seconds to probe all disks (before showing anything to the user) which I connected in this setup. While changing ntfs-config to use hal might be something good to do, as that should solve the issues, I have difficulty to think that it could reach the 10.3 gold master. So if we want to allow the user to mount NTFS partitions read-write without requiring him to use the shell to mount it as root by hand, we have to give ntfs-3g root privileges. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=293429#c15 Stephan Kulow <coolo@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dolarsrg@gmail.com --- Comment #15 from Stephan Kulow <coolo@novell.com> 2007-09-25 03:13:33 MST --- *** Bug 327476 has been marked as a duplicate of this bug. *** https://bugzilla.novell.com/show_bug.cgi?id=327476 -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=293429#c18 Ben Kevan <ben.kevan@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ben.kevan@gmail.com --- Comment #18 from Ben Kevan <ben.kevan@gmail.com> 2007-10-05 14:22:06 MST --- Modify fstab to umask=0002 And your done fstab is located /etc/fstab Then your set.. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=293429#c20 --- Comment #20 from Rastislav Krupanský <ra100@atlas.sk> 2007-10-06 01:12:55 MST --- great.thank you very much:-) -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=293429#c21 --- Comment #21 from Alberto Passalacqua <alberto.passalacqua@tin.it> 2007-10-21 16:09:15 MST --- Moving to final. Fstab is written by the installer with every sort of option but not with the right umask value. Regards, Alberto -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=293429 User lnussel@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=293429#c24 --- Comment #24 from Ludwig Nussel <lnussel@novell.com> 2008-11-05 02:34:49 MST --- Meanwhile the program ntfs-3g has been rewritten and is said to be secure now so it can be re-audited: http://article.gmane.org/gmane.comp.file-systems.ntfs-3g.devel/418 OTOH mounting should work via hal and without the setuid bit. -- 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.