Bugzilla – Bug 308867
Do not use "users" option for ntfs mounts
Last modified: 2009-10-13 23:49:40 UTC
Created attachment 162825 [details] Screenshot I've installed OpenSuse 10.3 Beta 2 on disk with Windows partitions (all updates before september 8 unstalled too). I have 3 windows disks: two NTFS and one FAT32. FAT32 disk mounted without problems. Both NTFS disks shown as not mounted after SUSE loaded. I use KDE 3.5.7. When i select "Mount" from popup menu, i've got an error: "Error opening partition device: Access denied" If i enter in KDE under root, than mounting works (working with disks too slow, but this is other question).
Please add /etc/fstab and the YaST logfiles (see http://en.opensuse.org/Bugs/YaST).
/dev/disk/by-id/scsi-SATA_ST3320620AS_3QF0YQ55-part8 / ext3 acl,user_xattr 1 1 /dev/disk/by-id/scsi-SATA_ST3320620AS_3QF0YQ55-part9 /archive ext3 acl,user_xattr 1 2 /dev/disk/by-id/scsi-SATA_ST3320620AS_3QF0YQ55-part1 /windows/C ntfs-3g users,gid=users,umask=0002,nls=utf8,locale=ru_RU.UTF-8 0 0 /dev/disk/by-id/scsi-SATA_ST3320620AS_3QF0YQ55-part5 /windows/D ntfs-3g users,gid=users,umask=0002,nls=utf8,locale=ru_RU.UTF-8 0 0 /dev/disk/by-id/scsi-SATA_ST3320620AS_3QF0YQ55-part6 /windows/E vfat users,gid=users,umask=0002,utf8=true 0 0 /dev/disk/by-id/scsi-SATA_ST3320620AS_3QF0YQ55-part7 swap swap defaults 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs noauto 0 0 debugfs /sys/kernel/debug debugfs noauto 0 0 usbfs /proc/bus/usb usbfs noauto 0 0 devpts /dev/pts devpts mode=0620,gid=5 0 0 /dev/fd0 /media/floppy auto noauto,user,sync 0 0
Created attachment 163379 [details] Yast logs part 1
Created attachment 163381 [details] Yast logs part 2
Bernd this seems to be a problem of xtfs-3g not honoring the "users" flag in /etc/fstab.
changing section '.. users,gid=users,umask=0002,nls=utf8,locale=ru_RU.UTF-8 0 0' to '... defaults 0 0' is a workaround fix. Not sure if this has other consequences
Same problem here with 10.3 x64 final. I am a bit reluctant to use defaults, as that wouldn't allow user mount as well
I made new installation of 10.3 for AMD64 from KDE CD and now all works fine. But few days ago, when i had Beta 2 with updates, mounting worked unstable. Sometimes both disks were mounted after booting, sometimes only one, sometimes both were not mounted. I haven't found any regularity for this... Now i downloading 10.3 DVD and will try reinstall Suse again.
Against reinstalled OpenSuse 10.3 GM - same problem, but not always!!! As i wrote before, sometimes all disks mounted after booting, sometimes only one, sometimes no one. Seems suse decides mount or not mount depending of moon phase :-)
See comment #16 in bug #309074 for an explanation of a ntfs-3g developer under which circumstances mounting of ntfs-3g fails. I still think the driver should fall back to a readonly-mount (with log entry explaining the reason for this) for such cases, but I can also understand the motivation of the developers to avoid the risk of even displaying invalid/outdated data under linux.
I've installed OpenSuse 10.3 and my windows partitions wasn't mounted, no /windows/<letter> directories created, unlike OpenSuse 10.2. I have fixed this by Yast disk module, adding manually mount point data.
Perhaps both are possible. The default behavior should be to fail the mount if the filesystem is inconsistent. A mount option should be provided to enable the fallback-to-readonly when the filesystem is inconsistent. I'll take it from here.
(In reply to comment #5 from Thomas Fehr) > Bernd this seems to be a problem of xtfs-3g not honoring the "users" flag in > /etc/fstab. ntfs-3g needs to be setuid root for the users flag to be honoured. Security team?
Not setting the setuid bit on that tool saved us from grave security problems in the past already (CVE-2007-5159). We will not set a setuid bit by default. Set the bit locally yourself if you are aware of the risks or mount the paritions via hal instead.
Moving to YaST: if we don't want to have a setuid ntfs-3g, then YaST shouldn't set the users option in fstab for ntfs mounts.
CVE-2007-5159 is a misunderstanding and obsolete for over 8 months, since the release of NTFS-3G 1.2216: http://ntfs-3g.org/releases.html NTFS-3G's security was reviewed and reworked 9 months ago. Using the built-in fuse-lite must be secure. No known risks are involved. Using external FUSE is unknown. More details are available from the 5th paragraphs at: http://article.gmane.org/gmane.comp.file-systems.ntfs-3g.devel/418
Security Team, please reevaluate.
*** Bug 440834 has been marked as a duplicate of this bug. ***
Well, an audit doesn't magically happen over night. ntfs-3g was on the radar previously and said security problems were discovered. We didn't receive a new audit request after the security model was changed. However IMO the setuid bit isn't needed anyways. HAL is able to mount fixed disks just fine in the meanwhile so no need for /etc/fstab entries anymore. Therefore my recommendation would be to only create fstab entries for partitions that are required by the system itself (/, /usr, swap etc) but not for partitions of other operating systems => yast's job to not create those /windows/* mounts I guess.
This is the very short story of the ntfs-3g security problems from over one year ago. All and even more were fixed in January and February of 2008. I can provide real person names offline if requested. A Fedora user noticed that if ntfs-3g and everything else is configured the documented way for unprivileged mounts to mount NTFS volumes then users can indeed mount unprivileged any NTFS volume. This was the intended behavior by design for those who needed this feature by explicit configuration (not default) but the user believed it is a security problem. A security advisory was issued by Fedora what other distributions followed without checking out the technical details. A Red Hat employee from their security team later confirmed me in private that the security analyses was incorrect what he approved. During the same time Ludwig Nussel from SUSE has found an unrelated, real local root exploit (much higher severity). This was never disclosed to the public but the incorrect security advisory is used today as a proxy. The CVE is still not analysed/confirmed. The solution would have been not trivial and involved the cooperation of several teams. Since the beginning of this year ntfs-3g has no dependency on FUSE user space and we was able to fully audit and fix all discovered security issues in ntfs-3g. Please note, the above doesn't mean setuid-root use would be encouraged by NTFS-3G. Actually just the opposite. But it's there for those who want to run (not only mount) ntfs-3g unprivileged. The user/user fstab option issue could be fixed if mount(8) called the mount.ntfs-3g mount helper privileged. Otherwise setuid-root ntfs-3g is required.
(In reply to comment #22 from Szabolcs Szakacsits) > A Fedora user noticed that if ntfs-3g and everything else is configured the > documented way for unprivileged mounts to mount NTFS volumes then users can > indeed mount unprivileged any NTFS volume. This was the intended behavior by > design for those who needed this feature by explicit configuration (not > default) but the user believed it is a security problem. > [...] > During the same time Ludwig Nussel from SUSE has found an unrelated, real local > root exploit (much higher severity). This was never disclosed to the public but > the incorrect security advisory is used today as a proxy. The CVE is still not > analysed/confirmed. You are right. I've dug up the discussions in the mail archive. Indeed CVE-2007-5376 has been assigned to problem I discovered and the plan was to reject CVE-2007-5159. This never actually happened though. Feel free to tell mitre (cve@mitre.org) to correct their descriptions. > Please note, the above doesn't mean setuid-root use would be encouraged by > NTFS-3G. Actually just the opposite. Good to hear :-) > The user/user fstab option issue could be fixed if mount(8) called the > mount.ntfs-3g mount helper privileged. Otherwise setuid-root ntfs-3g is > required. Yeah, other mount helpers would benefit from that too. One can't just change the semantics for current helpers though so one would need a directory where helpers with new sematics can be installed. Upstream is not opposed to this idea IIRC. There just is noone pushing an actual implementation. There are also efforts from the kernel side to allow pure user mounts without privileges.
(In reply to comment #23 from Ludwig Nussel) > Yeah, other mount helpers would benefit from that too. One can't just change > the semantics for current helpers though so one would need a directory where > helpers with new sematics can be installed. Upstream is not opposed to this > idea IIRC. There just is noone pushing an actual implementation. Last year I suggested a different mount helper name convention, e.g. /sbin/mount_<FS> (which is not really ok because it interferes with other OSes which do use '_' as [u]mount the '.'). I'm afraid a new directory would complicate things. Perhaps something like /sbin/root_mount.<FS>, /sbin/rmount.<FS>, /sbin/privileged_mount.<FS>, /sbin/prvmount.<FS>, ....? > There are also efforts from the kernel side to allow pure user mounts without > privileges. Afaik, Miklos is ready with it.
Changing YaST behaviour requires a fate entry.
CVE-2007-5159: CVSS v2 Base Score: 4.6 (AV:L/AC:L/Au:N/C:P/I:P/A:P)