Hello Daniel, On Thu, Jun 14, 2012 at 10:55:01PM +0200, Daniel Baumann wrote: > reopen 631504 > reopen 637805 > thanks > > On 06/14/2012 10:48 PM, Daniel Baumann wrote: > > see the other bug reports about this where i've commented on the issue. > > sorry, i though you opened a new bug.. anyhow, you've seen the reasoning > for not building ntfs-3g with internal fuse.
Actually, I didn't see it, sorry. "reportbug" is somewhat unintitive, apparently I just read the primary error descriptions and answered them. Using the WWW variant now. You probably mean this: "security reasons and no code-duplication. the remaining issues with using the systems fuse should be fixed in the code, the internal one is not an acceptable workaround." I strongly disagree with you in the point of view that using ntfs-3gs internal fuse implementation would be a security problem or just a "workaround". I understand that the author of ntfs-3g considers it a security issue if a setuid program relies on a potentially insecure external library. I can see his point, that using the internal fuse of ntfs-3g would actually increase security by reducing an entry point for attacks and makes ntfs-3g more atomic. About "code duplication": Have you actually checked if the internal fuse code is identical to the external one? I don't think it is. Even if it wastes a few bytes, I would rather trust the ntfs-3g authors fuse implementation because he designed ntfs-3g secure enough to allow it running as root with careful permission checks. If the external fuse libs get upgraded, this does not mean it is wise to also upgrade ntfs-3gs internal fuse implementation as well. At this point, I would now have to use a fork of ntfs-3g again, since normal users should be able to mount NTFS volumes without having to explicitly gain root access. With the current official package, this is not possible, and there is no working desktop integration of the ntfs-3g suite because of the privilege issues. Regards -Klaus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
