/run/media is an unnecessary divergence from the FHS

Bug #1020759 reported by Steve Langasek
34
This bug affects 6 people
Affects Status Importance Assigned to Milestone
udisks
Fix Released
Medium
udisks2 (Debian)
Fix Released
Unknown
udisks2 (Ubuntu)
Fix Released
Medium
Martin Pitt
Quantal
Fix Released
Medium
Martin Pitt

Bug Description

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.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: udisks2 1.98.0-2
ProcVersionSignature: Ubuntu 3.5.0-2.2-generic 3.5.0-rc4
Uname: Linux 3.5.0-2-generic x86_64
ApportVersion: 2.2.5-0ubuntu2
Architecture: amd64
CheckboxSubmission: 017452a27eca3c8b498abbfa5ef91db9
CheckboxSystem: ecaaad6fa1e0799a0aa1126bf620f39e
CustomUdevRuleFiles: 70-ssd-scheduler.rules 70-kvm-perms.rules
Date: Tue Jul 3 15:44:11 2012
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
MachineType: LENOVO 3249CTO
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.5.0-2-generic root=/dev/mapper/hostname-root ro quiet splash vt.handoff=7
SourcePackage: udisks2
UpgradeStatus: Upgraded to quantal on 2012-06-11 (22 days ago)
dmi.bios.date: 08/23/2010
dmi.bios.vendor: LENOVO
dmi.bios.version: 6QET52WW (1.22 )
dmi.board.name: 3249CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr6QET52WW(1.22):bd08/23/2010:svnLENOVO:pn3249CTO:pvrThinkPadX201:rvnLENOVO:rn3249CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 3249CTO
dmi.product.version: ThinkPad X201
dmi.sys.vendor: LENOVO

Related branches

Revision history for this message
Steve Langasek (vorlon) wrote :
Changed in udisks2 (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Sebastien Bacher (seb128) wrote :

The change was done in udisks2:
http://cgit.freedesktop.org/udisks/commit/?id=502fb5b7810afb50e48354e6b4d1781d07f79e10

There is no rational in the commit not reference to a list discussion or a bug though...

Revision history for this message
Martin Pitt (pitti) wrote :

FYI:
http://cgit.freedesktop.org/udisks/commit/?id=aa02e5fc53efdeaf66047d2ad437ed543178965b changed it to /run/media/.

http://cgit.freedesktop.org/udisks/commit/?id=9541a638ffd3b1bcb1b6ef6a8a00cc599a626093 is also interesting and hints 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, but let's discuss that with upstream first.

Revision history for this message
In , Sebastien Bacher (seb128) wrote :

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?

Revision history for this message
Sebastien Bacher (seb128) wrote :
Revision history for this message
In , Martin Pitt (pitti) wrote :

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?

Changed in udisks:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
In , Zeuthen (zeuthen) wrote :

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.

Revision history for this message
In , Zeuthen (zeuthen) wrote :

(For the second commit link I ofcourse meant

http://cgit.freedesktop.org/udisks/commit/?id=aa02e5fc53efdeaf66047d2ad437ed543178965b

instead. Sorry for the confusion.)

Revision history for this message
In , Zeuthen (zeuthen) wrote :

(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.

Revision history for this message
In , Sebastien Bacher (seb128) wrote :

Thanks for explanations David, that makes sense to me

Revision history for this message
In , Steve Langasek (vorlon) wrote :

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.

Revision history for this message
In , Zeuthen (zeuthen) wrote :

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...

Revision history for this message
Sebastien Bacher (seb128) wrote :

Steve, not sure you are subscribed to the upstream bug, it got closed NOTABUG, I copy the comment here

"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."

Revision history for this message
Steve Langasek (vorlon) wrote :

have followed up on the upstream bug.

Changed in udisks2 (Debian):
status: Unknown → New
Martin Pitt (pitti)
Changed in udisks2 (Ubuntu Quantal):
assignee: nobody → Martin Pitt (pitti)
status: Triaged → In Progress
milestone: none → ubuntu-12.10-beta-1
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package udisks2 - 1.99.0-2

---------------
udisks2 (1.99.0-2) experimental; urgency=low

  * Add mount_in_media.patch: Mount drives in /media, not /run/media/, to stay
    FHS compatible. (Closes: #680403, LP: #1020759)
 -- Martin Pitt <email address hidden> Wed, 22 Aug 2012 12:36:09 +0200

Changed in udisks2 (Ubuntu Quantal):
status: In Progress → Fix Released
Changed in udisks2 (Debian):
status: New → Fix Released
Revision history for this message
Timmie (timmie) wrote :

Hello,
how can I prevent /mount/<username>/<label>

and instead get

/mount/<label> ?

All backupscripts on external drives rely on this link.

e.g. beckintime uses a direct link to a folder.

Thanks.

Revision history for this message
Eric Forgeot (eforgeot) wrote :

@Timmie: This kind of "new behavior" which breaks everythink that was carefully configured before, annoys me as well.

I'm using several applications (unison in particular) on external drives, and all those the configuration files made references to /media/<label>, not /run/media/<username>/<label>, not to /media/<username>/<label>

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 has 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).

Revision history for this message
In , Eric Forgeot (eforgeot) wrote :

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.

Changed in udisks:
status: Confirmed → Invalid
Revision history for this message
In , Andi-1 (andi-1) wrote :

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

Changed in udisks:
status: Invalid → Confirmed
Revision history for this message
In , Phillip Susi (psusi) wrote :

(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.

Revision history for this message
In , Bob-q (bob-q) wrote :

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.

Revision history for this message
In , Martin Pitt (pitti) wrote :

I committed a patch to enable this with a configure option: http://cgit.freedesktop.org/udisks/commit/?id=ae2a5ff1e

Changed in udisks:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.