/media -> /run/media???

[Marcin Juszkiewicz]

Can someone point me to discussion which ended in /media being symlink
to /run/media directory?

I am now looking at Picasa rescanning 40GB of pictures just because
/media/storage/ dissapeared after upgrade of packages (which moved
/media/ to /media.rpmmoved/ one).

Should I create /my-own-directory-do-not-even-think-about-touching-it/
and keep mountpoints of all hard drives there just to hope that it will
stay there for next year?

[Lennart Poettering]

On Mon, 04.08.14 18:13, Marcin Juszkiewicz ([e-mail]) wrote:
> Can someone point me to discussion which ended in /media being symlink
> to /run/media directory?
>
> I am now looking at Picasa rescanning 40GB of pictures just because
> /media/storage/ dissapeared after upgrade of packages (which moved
> /media/ to /media.rpmmoved/ one).
>
> Should I create /my-own-directory-do-not-even-think-about-touching-it/
> and keep mountpoints of all hard drives there just to hope that it will
> stay there for next year?

Yes, you should.

/media was supposed to be the place where removable media is
automatically mounted. There are no rules on how things are named for
it, not whether the directory names are stable in any way. hal and
udisks used to mount stuff there, but they haven't done that since quite
a while now, since removable media should be private to the user, and a
system-wide namespace is inappropriate for that really. Thus it moved to
a user-private directory in /run/media/$USER/ instead, which nobody but
the user who is active on the seat the media was inserted to has access
to. This fixes a number of security problems since the namespace is
now private to the user, and a rogue user cannot confuse another user's
apps by taking possession of the /media path where they'd expect a
device to show up...

Now, while /run/media (and formerly /media) are under strictly automatic
control by udisks, the directory hierarchy /mnt is supposed to be under
admin control. If you want to mount arbitrary stuff to fixed places
following your own naming scheme, that's where you are supposed to mount
your stuff. If you want your removable media device to show up there,
simply edit /etc/fstab and add a line of your choice.

To make this more confusing, to my knowledge Ubuntu (or is it Debian as
its upstream?) actually patches /run/media/$UID back into /media. Or at
least I did that. It's stupid, and a security hole, and they should stop
doing that, but they know better...

The /media directory should probably be dropped from FHS, as it it's
really pointless, and is nothing one would ever use today. In fact, our
filesystem.rpm package should really stop shipping that (but then again,
I mean, it also ships /var/gopher, ...)

Lennart

[Lennart Poettering]

On Mon, 04.08.14 18:30, Lennart Poettering ([e-mail]) wrote:
> To make this more confusing, to my knowledge Ubuntu (or is it Debian as
> its upstream?) actually patches /run/media/$UID back into /media. Or at
> least I did that. It's stupid, and a security hole, and they shoul stop

^^^^ "it"...
> doing that, but they know better...

Lennart

[quickbooks office]

This issue came up recently for me.

I asked this on superuser:
https://superuser.com/questions/775882/what-do-i-have-to-do-so-i-can-get-2-u...

What do I have to do so I can get 2 users to be able to access disk
drives / partitions at the same time?

I mounted a disk drive using UserA ==> /run/media/userA/myDisk .

userB is a member of the same group of userA.

Why can userB not access the mountpoints?

What do I have to do so I can get 2 users to be able to access disk
drives / partitions at the same time?

Also to note the disks are encrypted.

I do not want chmod the files or directory to 777

==================

I really liked the answer:

udisks2 intentionally makes removable devices private to the user. (By
design, Linux is a multi-user system, and can potentially have several
people having separate seats (displays, keyboards, USB ports) and
connecting their own USB drives, so they should be separate from each
other.) So all per-user directories under /run/media are limited to
their owner only.

To make udisks2 place all mountpoints under /media, which it used to
do in the past, you can install a n udev rule by placing the following
in /etc/udev/rules.d/90-udisks2-shared.rules:

SUBSYSTEM=="block", ENV{UDISKS_FILESYSTEM_SHARED}="1"

Alternatively, you could move a specific device by configuring it in
/etc/fstab, e.g.:

/dev/mapper/luks-backups /mnt/backup auto noauto,nosuid,nodev,nofail,x-gvfs-show

In fact, you should always use /etc/fstab for internal or otherwise fixed disks.

However, this will only allow other users to reach the mountpoint, it
will not automatically allow them to browse files inside – you will
need to change the files' permissions. This depends on the filesystem
your disk is using.

If you use ext4, btrfs, or generally any filesystem that supports Unix
file ownership & permissions, use groupadd to create a dedicated group
for users allowed to access the disk; gpasswd -a to add them to the
group; then mount the disk and chown -R it to the newly created group.
Use chmod -R g+rwX to make all files group-accessible, and find
/mnt/disk -type d -exec chmod g+s {} + to make them inherit the group
ownership.

If you use fat32/vfat, do the same, but changing ownership or
permissions will not work; instead, you will need to add the gid=...
mount option in /etc/fstab. (The option should have the actual ID of
the group that you just added.)

========

I followed the first step and now I am able to access the mounts from
another user. The location now for me is /media

On Mon, Aug 4, 2014 at 9:30 AM, Lennart Poettering  wrote:
> On Mon, 04.08.14 18:13, Marcin Juszkiewicz ([e-mail]) wrote:
> > Can someone point me to discussion which ended in /media being symlink
> > to /run/media directory?
> >
> > I am now looking at Picasa rescanning 40GB of pictures just because
> > /media/storage/ dissapeared after upgrade of packages (which moved
> > /media/ to /media.rpmmoved/ one).
> >
> > Should I create /my-own-directory-do-not-even-think-about-touching-it/
> > and keep mountpoints of all hard drives there just to hope that it will
> > stay there for next year?
>
> Yes, you should.
>
> /media was supposed to be the place where removable media is
> automatically mounted. There are no rules on how things are named for
> it, not whether the directory names are stable in any way. hal and
> udisks used to mount stuff there, but they haven't done that since quite
> a while now, since removable media should be private to the user, and a
> system-wide namespace is inappropriate for that really. Thus it moved to
> a user-private directory in /run/media/$USER/ instead, which nobody but
> the user who is active on the seat the media was inserted to has access
> to. This fixes a number of security problems since the namespace is
> now private to the user, and a rogue user cannot confuse another user's
> apps by taking possession of the /media path where they'd expect a
> device to show up...
>
> Now, while /run/media (and formerly /media) are under strictly automatic
> control by udisks, the directory hierarchy /mnt is supposed to be under
> admin control. If you want to mount arbitrary stuff to fixed places
> following your own naming scheme, that's where you are supposed to mount
> your stuff. If you want your removable media device to show up there,
> simply edit /etc/fstab and add a line of your choice.
>
> To make this more confusing, to my knowledge Ubuntu (or is it Debian as
> its upstream?) actually patches /run/media/$UID back into /media. Or at
> least I did that. It's stupid, and a security hole, and they should stop
> doing that, but they know better...
>
> The /media directory should probably be dropped from FHS, as it it's
> really pointless, and is nothing one would ever use today. In fact, our
> filesystem.rpm package should really stop shipping that (but then again,
> I mean, it also ships /var/gopher, ...)
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> --
> devel mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Sérgio Basto]

On Seg, 2014-08-04 at 18:13 +0200, Marcin Juszkiewicz wrote:
> Can someone point me to discussion which ended in /media being symlink
> to /run/media directory?

https://bugzilla.redhat.com/show_bug.cgi?id=965918
> I am now looking at Picasa rescanning 40GB of pictures just because
> /media/storage/ dissapeared after upgrade of packages (which moved
> /media/ to /media.rpmmoved/ one).
>
> Should I create /my-own-directory-do-not-even-think-about-touching-it/
> and keep mountpoints of all hard drives there just to hope that it will
> stay there for next year?

[Ahmad Samir]

On 04/08/14 19:13, Marcin Juszkiewicz wrote:
> Can someone point me to discussion which ended in /media being symlink
> to /run/media directory?
>
> I am now looking at Picasa rescanning 40GB of pictures just because
> /media/storage/ dissapeared after upgrade of packages (which moved
> /media/ to /media.rpmmoved/ one).

[..]
> Should I create /my-own-directory-do-not-even-think-about-touching-it/
> and keep mountpoints of all hard drives there just to hope that it will
> stay there for next year?

Personally that's what I did eventually; this way I don't have to worry 
about the defaults changing - again - for whatever reasons in the future.

[Nico Kadel-Garcia]

> On Aug 5, 2014, at 3:28, Ahmad Samir  wrote:
> > On 04/08/14 19:13, Marcin Juszkiewicz wrote:
> > Can someone point me to discussion which ended in /media being symlink
> > to /run/media directory?
> >
> > I am now looking at Picasa rescanning 40GB of pictures just because
> > /media/storage/ dissapeared after upgrade of packages (which moved
> > /media/ to /media.rpmmoved/ one).
>
> [..]
> > Should I create /my-own-directory-do-not-even-think-about-touching-it/
> > and keep mountpoints of all hard drives there just to hope that it will
> > stay there for next year?
>
> Personally that's what I did eventually; this way I don't have to worry about the defaults changing - again - for whatever reasons in the future.

Fedora's recent tendency to override the published file system hierarchy specs, at whim, and replace them with symlinks is problematic, unnecessary, and is breaking things. In this case, /media is defined in the upstream specs as the location for removable media. Not /run/media. Not /whither/my/love/piñata/wanders/media.

Changing stable behavior because you think your model is better than the published spec is capricious and wastes time. In this case, in particular, it breaks tools that report disk usage of removable media because the real mountpoint just changed.

So, please, please, stop re-arranging the file system. The /bin symlink is bad enough, this one was pointless.

[Jon]

> Fedora's recent tendency to override the published file system hierarchy specs, at whim, and replace them with symlinks is problematic, unnecessary, and is breaking things. In this case, /media is defined in the upstream specs as the location for removable media. Not /run/media. Not /whither/my/love/piñata/wanders/media.

Are you referring to the File System Hierarchy (FHS 2.3) spec [1],
published in 2004, or the FHS 3 (beta) spec from 2011 [2] ?

Regardless, those specs (according to my reading) do not imperatively
[3] require a /media directory for removable media. It would appear
/media is preferable to legacy places like /mnt/cdrom, etc. They also
do not disallow for /run/media/$UID, only stipulating that these areas
be sensibly protected, which Fedora does.

Perhaps It would be nice to retain /media for situations where seated
users choose to mount media in an insecure (world accessible) way?

[1] http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html
[2] http://www.linuxbase.org/betaspecs/fhs/fhs.html
[3] https://www.ietf.org/rfc/rfc2119.txt

[Nico Kadel-Garcia]

On Wed, Aug 13, 2014 at 11:36 AM, Jon  wrote:
> > Fedora's recent tendency to override the published file system hierarchy specs, at whim, and replace them with symlinks is problematic, unnecessary, and is breaking things. In this case, /media is defined in the upstream specs as the location for removable media. Not /run/media. Not /whither/my/love/piñata/wanders/media.
>
> Are you referring to the File System Hierarchy (FHS 2.3) spec [1],
> published in 2004, or the FHS 3 (beta) spec from 2011 [2] ?
>
> Regardless, those specs (according to my reading) do not imperatively
> [3] require a /media directory for removable media. It would appear
> /media is preferable to legacy places like /mnt/cdrom, etc. They also
> do not disallow for /run/media/$UID, only stipulating that these areas
> be sensibly protected, which Fedora does.

I was referring to the older spec. The newer spec is more clear about
the use of /media. Neither *mandate* following the spec, that's very
difficult for any spec to do. The don't disallow replacing /etc/passwd
with symlinks, either. But the recent tendency to ignore the FSH and
history and pick a new location that may be "better" in some model of
the universe, but which breaks working processes, is problematic.

Also note that it's a pretty thorough violation of the more recent
spec to use "/run" for mountable media. If it hadn't been explicitly
specified, and it *was*, I'd have suggested using "/var/media".
> Perhaps It would be nice to retain /media for situations where seated
> users choose to mount media in an insecure (world accessible) way?

It's the removable media under /media/cdrom, /media/usb1, etc. that
would require more specific permissions. /var/run/media is no more or
less secdure than "/media". in that sense.
> [1] http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html
> [2] http://www.linuxbase.org/betaspecs/fhs/fhs.html
> [3] https://www.ietf.org/rfc/rfc2119.txt

RFC 2119 is from 1997. The world has evolved since then, and none of
"/run", "/var/run", nor "/media are mentioned.  I'm afraid stuffing
into /var/ was unnecessary, and the bugzilla mentioned never gave a
clear reason for the move.

[Ondřej Vašík]

On Wed, 2014-08-13 at 09:22 -0400, Nico Kadel-Garcia wrote:
> > On Aug 5, 2014, at 3:28, Ahmad Samir  wrote:
> > > On 04/08/14 19:13, Marcin Juszkiewicz wrote:
> > > Can someone point me to discussion which ended in /media being symlink
> > > to /run/media directory?
> > >
> > > I am now looking at Picasa rescanning 40GB of pictures just because
> > > /media/storage/ dissapeared after upgrade of packages (which moved
> > > /media/ to /media.rpmmoved/ one).
> >
> > [..]
> > > Should I create /my-own-directory-do-not-even-think-about-touching-it/
> > > and keep mountpoints of all hard drives there just to hope that it will
> > > stay there for next year?
> >
> > Personally that's what I did eventually; this way I don't have to worry about the defaults changing - again - for whatever reasons in the future.
>
> Fedora's recent tendency to override the published file system hierarchy specs, at whim, and replace them with symlinks is problematic, unnecessary, and is breaking things. In this case, /media is defined in the upstream specs as the location for removable media. Not /run/media. Not /whither/my/love/piñata/wanders/media.
>
> Changing stable behavior because you think your model is better than the published spec is capricious and wastes time. In this case, in particular, it breaks tools that report disk usage of removable media because the real mountpoint just changed.
>
> So, please, please, stop re-arranging the file system. The /bin symlink is bad enough, this one was pointless.

Actually I'm going to revert the /media -> /run/media change. It is
really not solving the issue it was trying to help with and in addition
it might be fragile in some cases. Sorry for the noise.

Regards,
         Ondrej

[Matthew Miller]

On Thu, Aug 14, 2014 at 10:06:11AM +0200, Ondrej Vasik wrote:
> Actually I'm going to revert the /media -> /run/media change. It is
> really not solving the issue it was trying to help with and in addition
> it might be fragile in some cases. Sorry for the noise.

Hmmmm... that should probablt be run through the change process... it needs
release notes at least!

[Ondřej Vašík]

On Thu, 2014-08-14 at 06:17 -0400, Matthew Miller wrote:
> On Thu, Aug 14, 2014 at 10:06:11AM +0200, Ondrej Vasik wrote:
> > Actually I'm going to revert the /media -> /run/media change. It is
> > really not solving the issue it was trying to help with and in addition
> > it might be fragile in some cases. Sorry for the noise.
>
> Hmmmm... that should probablt be run through the change process... it needs
> release notes at least!

Well, the directory was not used by default at all for several releases
- which was the reason for the initial idea about the symlink change -
initially it was supposed to be "noone will notice" change - but
although it can be such case for majority of the users, it doesn't bring
the expected benefits - which is the primary reason for the revert.

Regards,
       Ondrej

[Michal Schmidt]

On 08/14/2014 12:17 PM, Matthew Miller wrote:
> On Thu, Aug 14, 2014 at 10:06:11AM +0200, Ondrej Vasik wrote:
> > Actually I'm going to revert the /media -> /run/media change.

The above sentence is unfortunately ambiguous.
> > It is really not solving the issue it was trying to help with and in
> > addition it might be fragile in some cases. Sorry for the noise.
>
> Hmmmm... that should probablt be run through the change process... it needs
> release notes at least!

No, I'm sure Ondřej only meant that he'd revert the replacement
of the /media directory with a symlink to /run/media, which was in Rawhide
for only two weeks or so.

He does not intend to change the path where removable media get mounted.

Michal

[Nico Kadel-Garcia]

On Thu, Aug 14, 2014 at 11:49 AM, Michal Schmidt  wrote:
> On 08/14/2014 12:17 PM, Matthew Miller wrote:
> > On Thu, Aug 14, 2014 at 10:06:11AM +0200, Ondrej Vasik wrote:
> > > Actually I'm going to revert the /media -> /run/media change.
>
> The above sentence is unfortunately ambiguous.
> > > It is really not solving the issue it was trying to help with and in
> > > addition it might be fragile in some cases. Sorry for the noise.
> >
> > Hmmmm... that should probablt be run through the change process... it needs
> > release notes at least!
>
> No, I'm sure Ondřej only meant that he'd revert the replacement
> of the /media directory with a symlink to /run/media, which was in Rawhide
> for only two weeks or so.
>
> He does not intend to change the path where removable media get mounted.
>
> Michal

Ondrey, I hope that you meant you'd revert the entire change. and put
removeable media mounting back in /media. I've still not seen a single
reason for the move, only a bugzilla about getting it tot work
correctly. Following the more recent File System hierarchy documents
and putting it in the documented /media makes much more sense.

[Ondřej Vašík]

On Fri, 2014-08-15 at 08:07 -0400, Nico Kadel-Garcia wrote:
> On Thu, Aug 14, 2014 at 11:49 AM, Michal Schmidt  wrote:
> > On 08/14/2014 12:17 PM, Matthew Miller wrote:
> > > On Thu, Aug 14, 2014 at 10:06:11AM +0200, Ondrej Vasik wrote:
> > > > Actually I'm going to revert the /media -> /run/media change.
> >
> > The above sentence is unfortunately ambiguous.
> > > > It is really not solving the issue it was trying to help with and in
> > > > addition it might be fragile in some cases. Sorry for the noise.
> > >
> > > Hmmmm... that should probablt be run through the change process... it needs
> > > release notes at least!
> >
> > No, I'm sure Ondřej only meant that he'd revert the replacement
> > of the /media directory with a symlink to /run/media, which was in Rawhide
> > for only two weeks or so.
> >
> > He does not intend to change the path where removable media get mounted.
> >
> > Michal
>
> Ondrey, I hope that you meant you'd revert the entire change. and put
> removeable media mounting back in /media. I've still not seen a single
> reason for the move, only a bugzilla about getting it tot work
> correctly. Following the more recent File System hierarchy documents
> and putting it in the documented /media makes much more sense.

I just reverted the "two weeks in rawhide" symlink change
already. /media is no longer symlink in Rawhide. Removeable media mount
point is not under control of filesystem package (udisks2 mount them
to /run/media/$USER/$Volname ). 
Based on Michal's suggestion, you can use UDISKS_FILESYSTEM_SHARED set
to 1 to have removeable media mounted in /media instead
of /run/media/$USER/ .

Regards,
       Ondrej
> -- 
> devel mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Nico Kadel-Garcia]

On Fri, Aug 15, 2014 at 9:47 AM, Ondrej Vasik  wrote:
> On Fri, 2014-08-15 at 08:07 -0400, Nico Kadel-Garcia wrote:
> > On Thu, Aug 14, 2014 at 11:49 AM, Michal Schmidt  wrote:
> > > On 08/14/2014 12:17 PM, Matthew Miller wrote:
> > > > On Thu, Aug 14, 2014 at 10:06:11AM +0200, Ondrej Vasik wrote:
> > > > > Actually I'm going to revert the /media -> /run/media change.
> > >
> > > The above sentence is unfortunately ambiguous.
> > > > > It is really not solving the issue it was trying to help with and in
> > > > > addition it might be fragile in some cases. Sorry for the noise.
> > > >
> > > > Hmmmm... that should probablt be run through the change process... it needs
> > > > release notes at least!
> > >
> > > No, I'm sure Ondřej only meant that he'd revert the replacement
> > > of the /media directory with a symlink to /run/media, which was in Rawhide
> > > for only two weeks or so.
> > >
> > > He does not intend to change the path where removable media get mounted.
> > >
> > > Michal
> >
> > Ondrey, I hope that you meant you'd revert the entire change. and put
> > removeable media mounting back in /media. I've still not seen a single
> > reason for the move, only a bugzilla about getting it tot work
> > correctly. Following the more recent File System hierarchy documents
> > and putting it in the documented /media makes much more sense.
>
> I just reverted the "two weeks in rawhide" symlink change
> already. /media is no longer symlink in Rawhide. Removeable media mount
> point is not under control of filesystem package (udisks2 mount them
> to /run/media/$USER/$Volname ).
> Based on Michal's suggestion, you can use UDISKS_FILESYSTEM_SHARED set
> to 1 to have removeable media mounted in /media instead
> of /run/media/$USER/ .

*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.
Files in /run are supposed to be scrubbed or truncated at boot time!!!

Think I can get any traction getting that default reset at this point?

[Andrew Lutomirski]

On Aug 15, 2014 7:21 PM, "Nico Kadel-Garcia"  wrote:
> On Fri, Aug 15, 2014 at 9:47 AM, Ondrej Vasik  wrote:
> > On Fri, 2014-08-15 at 08:07 -0400, Nico Kadel-Garcia wrote:
> > > On Thu, Aug 14, 2014 at 11:49 AM, Michal Schmidt

wrote:
> > > > On 08/14/2014 12:17 PM, Matthew Miller wrote:
> > > > > On Thu, Aug 14, 2014 at 10:06:11AM +0200, Ondrej Vasik wrote:
> > > > > > Actually I'm going to revert the /media -> /run/media change.
> > > >
> > > > The above sentence is unfortunately ambiguous.
> > > > > > It is really not solving the issue it was trying to help with and

in
> > > > > > addition it might be fragile in some cases. Sorry for the noise.
> > > > >
> > > > > Hmmmm... that should probablt be run through the change process...

it needs
> > > > > release notes at least!
> > > >
> > > > No, I'm sure Ondřej only meant that he'd revert the replacement
> > > > of the /media directory with a symlink to /run/media, which was in

Rawhide
> > > > for only two weeks or so.
> > > >
> > > > He does not intend to change the path where removable media get

mounted.
> > > > Michal
> > >
> > > Ondrey, I hope that you meant you'd revert the entire change. and put
> > > removeable media mounting back in /media. I've still not seen a single
> > > reason for the move, only a bugzilla about getting it tot work
> > > correctly. Following the more recent File System hierarchy documents
> > > and putting it in the documented /media makes much more sense.
> >
> > I just reverted the "two weeks in rawhide" symlink change
> > already. /media is no longer symlink in Rawhide. Removeable media mount
> > point is not under control of filesystem package (udisks2 mount them
> > to /run/media/$USER/$Volname ).
> > Based on Michal's suggestion, you can use UDISKS_FILESYSTEM_SHARED set
> > to 1 to have removeable media mounted in /media instead
> > of /run/media/$USER/ .
>
> *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.
> Files in /run are supposed to be scrubbed or truncated at boot time!!!
>
> Think I can get any traction getting that default reset at this point?

No, because:

- Security

- Automatically generated names will never reliably match you expectation
in /media no matter what udisks does.

--Andy
> --
> devel mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Jon]

On Fri, Aug 15, 2014 at 9:21 PM, Nico Kadel-Garcia  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.
> Files in /run are supposed to be scrubbed or truncated at boot time!!!

$ findmnt  /run
TARGET SOURCE FSTYPE OPTIONS
/run   tmpfs  tmpfs  rw,nosuid,nodev,seclabel,mode=755
> Think I can get any traction getting that default reset at this point?

Unlikely.

[1] http://www.linuxbase.org/betaspecs/fhs/fhs.html#runRuntimeVariableData

[Nico Kadel-Garcia]

On Sat, Aug 16, 2014 at 1:54 PM, Jon  wrote:
> On Fri, Aug 15, 2014 at 9:21 PM, Nico Kadel-Garcia  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.

[Robert Nichols]

On 08/17/2014 12:31 PM, Nico Kadel-Garcia wrote:
> On Sat, Aug 16, 2014 at 1:54 PM, Jon  wrote:
> > 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.

The media would not get scrubbed since it is not yet mounted at that
point in the boot sequence. What _does_ get scrubbed is any leftover
/run/media/$USER directories and the temporary mount points they
contain, which is arguably preferable to allowing that cruft to
accumulate in /media.

[Nico Kadel-Garcia]

On Sun, Aug 17, 2014 at 9:12 PM, Robert Nichols
 wrote:
> The media would not get scrubbed since it is not yet mounted at that
> point in the boot sequence. What _does_ get scrubbed is any leftover
> /run/media/$USER directories and the temporary mount points they
> contain, which is arguably preferable to allowing that cruft to
> accumulate in /media.

Good luck with that. In a world where udisk2 was the only thing that
mounted in /run/media/$user/medianame directories, that could be maybe
relied on. But it's reliant on well behaved applications to follow a
standard overlaid on top of a misreading of the file system hierarchy

As soon as someone else follows the _practice_ of mounting things in
/run/media, and doesn't follow the extra and underdocumented
requirements of protecting /run/media/$username, you're in trouble.

Sorry, it was an unnecessary change from day one. /media was already
specified for just such removable media uses.

[Reindl Harald]

Am 18.08.2014 um 03:42 schrieb Nico Kadel-Garcia:
> On Sun, Aug 17, 2014 at 9:12 PM, Robert Nichols
>  wrote:
> > The media would not get scrubbed since it is not yet mounted at that
> > point in the boot sequence. What _does_ get scrubbed is any leftover
> > /run/media/$USER directories and the temporary mount points they
> > contain, which is arguably preferable to allowing that cruft to
> > accumulate in /media.
>
> Good luck with that. In a world where udisk2 was the only thing that
> mounted in /run/media/$user/medianame directories, that could be maybe
> relied on. But it's reliant on well behaved applications to follow a
> standard overlaid on top of a misreading of the file system hierarchy

you refuse to understand what a mountpoint is

* dynamic mountpoint get created
* media is mounted in that mountpoint
* on shutdown any media is unoumted unconditionally
* since the mountpoint is on tmpfs, well the empty dir don't exist after reboot
* nothing there scrubs the media, that's just not possible, there is no rm -rf anywhere
> As soon as someone else follows the _practice_ of mounting things in
> /run/media, and doesn't follow the extra and underdocumented
> requirements of protecting /run/media/$username, you're in trouble.
>
> Sorry, it was an unnecessary change from day one. /media was already
> specified for just such removable media uses

well, agreed, but stop to pretend media get scrubbed

[Lennart Poettering]

On Fri, 15.08.14 22:21, Nico Kadel-Garcia ([e-mail]) wrote:
> > I just reverted the "two weeks in rawhide" symlink change
> > already. /media is no longer symlink in Rawhide. Removeable media mount
> > point is not under control of filesystem package (udisks2 mount them
> > to /run/media/$USER/$Volname ).
> > Based on Michal's suggestion, you can use UDISKS_FILESYSTEM_SHARED set
> > to 1 to have removeable media mounted in /media instead
> > of /run/media/$USER/ .
>
> *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

Well, I am pretty sure we have the duty to implemen an operating system
that is secure by default.
> use of "/run" and "/var/run" for pid files, not for removable media.
> Files in /run are supposed to be scrubbed or truncated at boot time!!!

Yeah, that's why we mount them to /run, so that the mount points of
dynamically plugged in drives stay around on physical media. Dynamic
stuff shouldn't be placed on persistent disks.

This change has been made a long time ago and for good reasons, I really
don't see a point in complaining about this now.

Lennart

[Richard W.M. Jones]

On Mon, Aug 18, 2014 at 02:21:19PM +0200, Lennart Poettering wrote:
> On Fri, 15.08.14 22:21, Nico Kadel-Garcia ([e-mail]) wrote:
> > > I just reverted the "two weeks in rawhide" symlink change
> > > already. /media is no longer symlink in Rawhide. Removeable media mount
> > > point is not under control of filesystem package (udisks2 mount them
> > > to /run/media/$USER/$Volname ).
> > > Based on Michal's suggestion, you can use UDISKS_FILESYSTEM_SHARED set
> > > to 1 to have removeable media mounted in /media instead
> > > of /run/media/$USER/ .
> >
> > *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
>
> Well, I am pretty sure we have the duty to implemen an operating system
> that is secure by default.

What's the security issue?  The bug (965918) doesn't mention one.

Rich.

[Lennart Poettering]

On Mon, 18.08.14 13:25, Richard W.M. Jones ([e-mail]) wrote:
> On Mon, Aug 18, 2014 at 02:21:19PM +0200, Lennart Poettering wrote:
> > On Fri, 15.08.14 22:21, Nico Kadel-Garcia ([e-mail]) wrote:
> > > > I just reverted the "two weeks in rawhide" symlink change
> > > > already. /media is no longer symlink in Rawhide. Removeable media mount
> > > > point is not under control of filesystem package (udisks2 mount them
> > > > to /run/media/$USER/$Volname ).
> > > > Based on Michal's suggestion, you can use UDISKS_FILESYSTEM_SHARED set
> > > > to 1 to have removeable media mounted in /media instead
> > > > of /run/media/$USER/ .
> > >
> > > *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
> >
> > Well, I am pretty sure we have the duty to implemen an operating system
> > that is secure by default.
>
> What's the security issue?  The bug (965918) doesn't mention one.

You don't want a shared namespace with other users, you want a per-user
namespace where you mount stuff. Otherwise other users on the system can
trick you into using the wrong usb stick, if you plug in two, simply by
choosing the same volume label as yours.

Lennart

[Ondřej Vašík]

On Mon, 2014-08-04 at 18:13 +0200, Marcin Juszkiewicz wrote:
> Can someone point me to discussion which ended in /media being symlink
> to /run/media directory?
>
> I am now looking at Picasa rescanning 40GB of pictures just because
> /media/storage/ dissapeared after upgrade of packages (which moved
> /media/ to /media.rpmmoved/ one).

This is pretty strange - so /media.rpmmoved was empty and without these
40GB of pictures? This directory was supposed to be created (with
os.rename) for such cases when people had their own files/dirs in /media
- for safety.
> Should I create /my-own-directory-do-not-even-think-about-touching-it/
> and keep mountpoints of all hard drives there just to hope that it will
> stay there for next year?

Well, it would be better to use /usr/local or /opt for this - not
creating another one toplevel directory for these do-not-ever-touch
mounts.

Greetings,
         Ondrej Vasik