|Summary:||/run/media is an unnecessary divergence from the FHS|
|Product:||udisks||Reporter:||Sebastien Bacher <seb128>|
|Component:||general||Assignee:||David Zeuthen (not reading bugmail) <zeuthen>|
|Status:||RESOLVED FIXED||QA Contact:|
|i915 platform:||i915 features:|
Description Sebastien Bacher 2012-07-04 01:44:53 UTC
The bug has been opened on https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1020759 "The FHS specifies that /media should be used as the mountpoint for removeable media. The udisks2 change to use /run/media instead is an unwarranted divergence from the standard and from existing practice, violating the expectations of experienced users and possibly breaking user scripts / symlinks. Please fix udisks to move its mounts back to /media." I've been looking the commits and found http://cgit.freedesktop.org/udisks/commit/?id=502fb5b7810afb50e48354e6b4d1781d07f79e10 but it has no real rational for the change nor pointer to a discussion,bug with details. I guess there is a motivation behind the change, is it documented somewhere. Would you consider having the behaviour optional for distributions which prefer to keep respecting the FHS location?
Comment 1 Martin Pitt 2012-07-04 01:47:55 UTC
http://cgit.freedesktop.org/udisks/commit/?id=9541a638ffd is an interesting and hint why this was done: In a multi-seat scenario it is more robust to mount them below a per-user directory so that devices from different users are less likely to collide on identical label names. This also shields mounts from different users from each other, which looks like a security measure. Apparently it can be changed to the old behaviour by udev-tagging devices with ID_SEAT=all, though. As for the /media -> /run/media change, I presume this was done to avoid having to clean up stale mount point directories after reboot?
Comment 2 David Zeuthen (not reading bugmail) 2012-07-05 06:46:14 UTC
The motivation for moving out of /media was that with /media any user can access the filesystem that your user mounts. Which obviously is highly undesirable on multi-user systems. Originally we wanted to use $XDG_USER_RUNTIME_DIR and for a while we did that, see http://cgit.freedesktop.org/udisks/commit/?id=502fb5b7810afb50e48354e6b4d1781d07f79e10 but shortly determined that it was racy (it's never a good idea for a system daemon to write to a directory controlled by untrusted users) so we ended up using /run/media instead: http://cgit.freedesktop.org/udisks/commit/?id=502fb5b7810afb50e48354e6b4d1781d07f79e10 (OTOH, if you really want all users to access a device, you simply just add an /etc/fstab entry. We now have API in udisks and UI in GNOME Disks for this.) > violating the expectations of experienced users and possibly > breaking user scripts / symlinks. Just FYI, it's pretty fragily to rely on udisks just this or that name in /media in the first place so I don't think any "experienced user" would do this. If you need a predictable mount point, you need to use /etc/fstab or mount the device yourself through another mechanism. Or, better, fix your software and/or scripts to figure out the mount point itself by looking at things like /proc/self/mountinfo use lsblk(8) or whatever. > Please fix udisks to move its mounts back to /media." There is nothing to "fix" here so closing NOTABUG.
Comment 3 David Zeuthen (not reading bugmail) 2012-07-05 06:48:05 UTC
(For the second commit link I ofcourse meant http://cgit.freedesktop.org/udisks/commit/?id=aa02e5fc53efdeaf66047d2ad437ed543178965b instead. Sorry for the confusion.)
Comment 4 David Zeuthen (not reading bugmail) 2012-07-05 06:55:54 UTC
(In reply to comment #1) > As for the /media -> /run/media change, I presume this was done to avoid having > to clean up stale mount point directories after reboot? Well, yeah, kinda - the idea is that such temporary mounts really are non-persistent => they belong somewhere in /run instead of a top-level like /media (although on Fedora, /media was already on tmpfs since F15 or so). Just for the record I also don't think that having a "standard" mandate where removable media is mounted is in any way useful for users or distributors.
Comment 5 Sebastien Bacher 2012-07-05 07:40:49 UTC
Thanks for explanations David, that makes sense to me
Comment 6 Steve Langasek 2012-07-05 08:13:25 UTC
David, I'm not happy about the per-user subdirectories either, but I understand the motivation and that's not what this bug is about. I was reporting a bug because udisks is moving the mounts out from under /media to /run/media, and this is a violation of the FHS. If distros want to take advantage of /run to auto-clean mount points on reboot, they can make /media a symlink to /run/media - but udisks should still be creating its directories relative to /media, because that's what the FHS mandates.
Comment 7 David Zeuthen (not reading bugmail) 2012-07-05 09:32:59 UTC
No. What the FHS says about removable media is not in any way useful (it was written a long time ago too, last revision is 2004). And using big words like "violate" or "mandate" is not going to change any of that, sorry. You really should know better...
Comment 8 eric f 2013-01-13 08:58:40 UTC
This kind of "new behavior" which breaks everythink that was carefully configured before, annoys me as well. ("it's not a bug, it's a feature") I'm using several applications (unison in particular) on external drives, and for them when I made my user configurations I made references to /media/<label>, not /run/media/<username>/<label>, not to /media/<username>/<label> (like Debian did) It's especially annoying for tools such as Unison which have a database of all changes made on disks, and can't refer to the correct names because it was arbitrary changed, so you must forget all the previous history and build a new one, which is long and tedious for huge external drives. Come on, who is ever using a Linux Desktop for several users, AND at the same time needs security so they can plug different usb keys or external drives simultaneously? In more than 99% of the cases, it won't be necessary, and in the rare cases it could be necessary (multiseat), this kind of behavior could be set as an option, for example in a damn /etc/udisks2.conf On the other hand, if security was such an issue, /media/<username>/<label> could still have been kept, but the permissions for the folder could have been set in r/w only for the one who had inserted the key. After all, it doesn't prevent security to have /home/user1 and /home/user2 under the same folder. For my part I could "fix" this by installing udisks (v1) and removing udisks2 and all its dependencies (including gnome, mate etc). If you feel you really need to make a fondamental behavior change in a product, please use opt-in instead, and make an option to enable the new behavior, instead of the opposite.
Comment 9 Andreas Teuben 2013-02-09 21:36:11 UTC
I'm using Ubuntu (Xubuntu), and starting with 12.10 my USB flash drives and USB hard discs are mounted to /media/$USER/ instead of /media/. As far as I know, this is because of the change discussed in this bug report. When I'm logged in as user X and plug a USB device, no one but user X can access to this device. That's a problem for me (and - in my opinion - a bug). Usually there are two, three of four accounts working on my computer simultaneously. They all need access to some data on USB devices. I use ext3/ext4 file permissions on my USB devices to control, who is allowed to access which data. This worked with Ubuntu 12.04, but it doesn't work any more with Ubuntu 12.10. Authorized users can't access their data any more, because they can't access to /media/$USER. Is it possible to allow all users to access to any plugged USB device? If "yes": How can I get this behaviour. If "no": When this bug is estimated to be repaired? Thanks Andi
Comment 10 Phillip Susi 2013-11-04 21:14:25 UTC
(In reply to comment #2) > The motivation for moving out of /media was that with /media any user can > access the filesystem that your user mounts. This isn't true. The filesystem is mounted so that only the mounting user has permissions.
Comment 11 Bob Smits 2013-11-29 05:26:40 UTC
I heartily concur with those who resent having their unison links not working because of a scheme for "improvements" none of us asked for or want. I don't even mind all that much of the location changes from /media to something else as long as unison can still find what the something else is. At this point you've broken unison, and I don't see any suggestion here about fixing this problem.
Comment 12 Martin Pitt 2015-01-13 14:37:10 UTC
I committed a patch to enable this with a configure option: http://cgit.freedesktop.org/udisks/commit/?id=ae2a5ff1e