[Bug 337739] New: Allow the user to mount removable devices in $HOME
https://bugzilla.novell.com/show_bug.cgi?id=337739 Summary: Allow the user to mount removable devices in $HOME Product: openSUSE 10.3 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: KDE AssignedTo: kde-maintainers@suse.de ReportedBy: sven.burmeister@gmx.net QAContact: qa@suse.de Found By: --- If I attach a removable device I can set the mount-dir in its settings. However this is restricted to /media. If a user e.g. uses an external harddrive as documents-folder or any other location in its home, one is forced to set it up via fstab, which leads to issues when the computer boots and the device is not attached. -- 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=337739#c1 Robert Davies <rob.opensuse.linux@googlemail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rob.opensuse.linux@googlemail.com --- Comment #1 from Robert Davies <rob.opensuse.linux@googlemail.com> 2007-10-31 18:45:06 MST --- I see a problem with this (but I'm a sys admin not an end user). mount(2) system call mounts paths and you need CAP_SYS_ADMIN to do it. Unfortunately there's not a call to mount on an open directory file descriptor. That means that the access control, cannot be atomic with the mount, you will check a path, it looks good, and you decide to allow the mount, but there's no way of knowing if the mount(2) actually put the mount on the directory. So clever user... You prepare on your removeable media, a new /etc directory copied from a system where you have root access. Then you make a directory "foou/etc" in your HOME directory. Now you type "mv foou bar; ln -s / foou", and you repeat this until you time it just right and have the mount(2) call overlay the system /etc. Of course there's a system call to rename a file atomically, so you've more chance from a C program than from command line with multiple processes. Seems unlikely but so many systems have been cracked in past by such methods, due to the race conditions. Therefore requiring write access to /etc/fstab and making sure that is root owned and only root writeable matters for security. I don't see how even chroot-ing the mounter will help things as the point & click user will want access from the normal system, and they won't be chroot-ed. You could perhaps create a 'fake' root sub-directory in HOME where the .. inode entry was ., and have the mounter check on the inode of the mount point, and it's .. entry, but that'll cause problems to programs that crawl around the filesystem. If a user wants to conveniently copy files out from the inserted media, perhaps they should create symlinks to their target directories, rather than be allowed free choice of mount points. -- 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=337739 Dirk Mueller <dmueller@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 - Medium |P2 - High -- 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=337739 Dirk Mueller <dmueller@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium -- 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.
participants (1)
-
bugzilla_noreply@novell.com