On Sat, Aug 16, 2014 at 1:54 PM, Jon jdisnard@gmail.com wrote:
On Fri, Aug 15, 2014 at 9:21 PM, Nico Kadel-Garcia nkadel@gmail.com wrote:
...
*sigh*. Then the default should have been to set UDISKS_FILESYSTEM_SHARED to 1. Let people who *want* it in the new "/run/media/$USER/mountdir" select it. And it's *still* a violation of even the most recent filesystem hierarchy standards, which discuss the use of "/run" and "/var/run" for pid files, not for removable media.
Not a violation.
From the beta spec: "Programs may have a subdirectory of /run; this is encouraged for programs that use more than one run-time file. Users may also have a subdirectory of /run, although care must be taken to appropriately limit access rights to prevent unauthorized use of /run itself and other subdirectories." [1]
The rationale here is that media mounts for a seated user are part of that users run-time, or session. By placing them in an area exclusive to the seated user, the system as a whole is more secure.
And that could have been put at "/media/$username/$medianame". Not one part of that security practice change required using "/run" Calling stored content, typically used across multiple sessions and often used for archival or non-writable storage, part of the "run-time" data is a serious misreading of what the "run-time" data of the FHS spec describes. The language is clearly aimed at PID data and similar boot-time erasable data.
I've never personally used attachable media that I scrubbed, or expected to be scrubbale, with everey reboot.