Mike Hommey wrote: On Fri, Oct 05, 2007 at 08:26:35PM +0200, Adam CĂŠcile (Le_Vert) wrote: > > The best thing to do would be to have ntfs-3g fall back to exec()ing > fusermount(1) as plain libfuse does when mount(2) fails.
It would fail with "fusermount: option blkdev is privileged" error message. The only solution is http://ntfs-3g.org/support.html#useroption3 CVE-2007-5159 is a misunderstanding and obsolete for over 11 months, since the release of NTFS-3G 1.2216: http://ntfs-3g.org/releases.html NTFS-3G's security was reviewed and reworked one year ago. Using the built-in fuse-lite is 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 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. Regards, Szaka -- NTFS-3G: http://ntfs-3g.org -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
