Bug#680403: udisks2 mounts devices in a non-FHS-compliant directory

July 05th, 2012 - 01:20 pm ET by Steve Langasek | Report spam
Package: udisks2
Version: 1.98.0-2
Severity: serious
Justification: FHS

udisks2 has taken to mounting user filesystems under /run/media. This
directly contradicts the FHS, which says /media is to be used for mounting
removeable media.

This is therefore a serious policy violation in the udisks2 package.

This bug has also been reported upstream and upstream has refused to correct
the issue: https://bugs.freedesktop.org/show_bug.cgi?idQ709

Debian Release: wheezy/sid
APT prefers quantal-updates
APT policy: (500, 'quantal-updates'), (500, 'quantal-security'), (500, 'quantal')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
armhf

Kernel: Linux 3.5.0-2-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages udisks2 depends on:
ii dbus 1.4.18-1ubuntu1
ii libacl1 2.2.51-8ubuntu1
ii libatasmart4 0.19-1git1
ii libc6 2.15-0ubuntu15
ii libglib2.0-0 2.33.3-2
ii libgudev-1.0-0 1:175-0ubuntu10
ii libpolkit-agent-1-0 0.104-2ubuntu1
ii libpolkit-gobject-1-0 0.104-2ubuntu1
ii libudisks2-0 1.98.0-2
ii udev 175-0ubuntu10

Versions of packages udisks2 recommends:
ii dosfstools 3.0.12-1ubuntu1
ii eject 2.1.5+deb1+cvs20081104-11
ii mtools 4.0.17-1
ii ntfs-3g 1:2012.1.15AR.5-2ubuntu1
ii policykit-1 0.104-2ubuntu1

Versions of packages udisks2 suggests:
ii cryptsetup-bin 2:1.4.1-2ubuntu4
ii mdadm 3.2.5-1ubuntu2
ii reiserfsprogs 1:3.6.21-1build1
pn xfsprogs <none>




To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
email Follow the discussionReplies 4 repliesReplies Make a reply

Similar topics

Replies

#1 Michael Biebl
July 05th, 2012 - 01:50 pm ET | Report spam
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)

On 05.07.2012 19:12, Steve Langasek wrote:
Package: udisks2
Version: 1.98.0-2
Severity: serious
Justification: FHS

udisks2 has taken to mounting user filesystems under /run/media. This
directly contradicts the FHS, which says /media is to be used for mounting
removeable media.

This is therefore a serious policy violation in the udisks2 package.

This bug has also been reported upstream and upstream has refused to correct
the issue: https://bugs.freedesktop.org/show_bug.cgi?id=51709



We've implemented /run despite it not being in the FHS.

If there are good technical arguments for mounting removable media under
/run/media (and I notice a few in the upstream bug report), I don't see
why we shouldn't consider diverging from the FHS here.

Michael


Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?







To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Replies Reply to this message
#2 Steve Langasek
July 05th, 2012 - 02:30 pm ET | Report spam

On Thu, Jul 05, 2012 at 07:34:21PM +0200, Michael Biebl wrote:
On 05.07.2012 19:12, Steve Langasek wrote:
> Package: udisks2
> Version: 1.98.0-2
> Severity: serious
> Justification: FHS

> udisks2 has taken to mounting user filesystems under /run/media. This
> directly contradicts the FHS, which says /media is to be used for mounting
> removeable media.

> This is therefore a serious policy violation in the udisks2 package.

> This bug has also been reported upstream and upstream has refused to correct
> the issue: https://bugs.freedesktop.org/show_bug.cgi?id=51709

We've implemented /run despite it not being in the FHS.



We've implemented /run, as a special exception approved in Debian Policy,
for those bits of the filesystem previously stored in /var/run and
/var/lock. No such exception has been granted for /media, nor should there
be.

If there are good technical arguments for mounting removable media under
/run/media (and I notice a few in the upstream bug report), I don't see
why we shouldn't consider diverging from the FHS here.



No, there are no good technical arguments for the move. There's a technical
justification given for creating per-user subdirectories, there is *not* a
technical reason for the move to /run. This is a gratuitous incompatibility
with the FHS.

Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/







To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Replies Reply to this message
#3 Michael Biebl
July 05th, 2012 - 02:40 pm ET | Report spam
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)

On 05.07.2012 20:18, Steve Langasek wrote:

We've implemented /run despite it not being in the FHS.



We've implemented /run, as a special exception approved in Debian Policy,
for those bits of the filesystem previously stored in /var/run and
/var/lock. No such exception has been granted for /media, nor should there
be.



Just for clarification, this exception was added after /run had already
been implemented.
Neither the FHS nor the debian-policy are set in stone and e.g. the FHS
eventually caught up what was implemented by the distros.


Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?







To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Replies Reply to this message
#4 Steve Langasek
July 05th, 2012 - 02:50 pm ET | Report spam

On Thu, Jul 05, 2012 at 08:27:43PM +0200, Michael Biebl wrote:
On 05.07.2012 20:18, Steve Langasek wrote:

>> We've implemented /run despite it not being in the FHS.

> We've implemented /run, as a special exception approved in Debian Policy,
> for those bits of the filesystem previously stored in /var/run and
> /var/lock. No such exception has been granted for /media, nor should there
> be.

Just for clarification, this exception was added after /run had already
been implemented.



No, it was discussed on debian-policy before it was implemented in sysvinit.

Neither the FHS nor the debian-policy are set in stone and e.g. the FHS
eventually caught up what was implemented by the distros.



Neither the FHS nor Debian Policy generally can be ignored by packages in
Debian.

Your package is in violation of Policy. Fix it. If you don't like Policy,
file a bug against debian-policy about it - but there's no good reason at
all for this change, and Debian does not change its filesystem policy every
time an upstream decides to ignore it for no good reason.

Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/







To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
email Follow the discussion Replies Reply to this message
Help Create a new topicReplies Make a reply
Search Make your own search