Introducing pmount in Debian / New plugdev group

1 view
Skip to first unread message

Martin Pitt

unread,
Nov 9, 2004, 12:50:39 PM11/9/04
to
Hi Debian developers!

I am currently responsible for developing the GNOME Utopia stack for
Ubuntu and closely work together with Sjoerd Simons who maintains the
Debian packages (gnome-volume-manager, hal).

Upstream's idea of automatic USB/FireWire device handling is as
follows: the "hal" daemon runs as root, is notified by hotplug about
added/removed devices, and adds/removes lines to /etc/fstab for these
devices. This allows gnome-volume-manager to mount/unmount
hotpluggable devices as normal user.

However, I was not satisfied with this solution because of several
reasons:

1. Hal's concept is to be a hardware database; it should be policy free
and not actually change anything in the system.

2. I do not like programs who mess with a central configuration file
like /etc/fstab. A crash at the wrong time, and your system is
unbootable.

3. In the last months I found so many segfaults in hal that I outright
refuse to let hal run as root. Besides, previous versions allowed
all users to modify any key in the database, so it could not be
trusted anyway. Even now hal has so many bugs that I feel it is
insane to run it as root.

I made some modifications to hald which allows it to run as normal
user 'hal' with some additional privileges (group membership and
kernel capabilities). These modifications went upstream.

4. The security policy of Ubuntu implies that we strictly separate
system volumes and user accessible drives. An administrator must be
able to trust the integrity of his system partitions (/, /home,
/usr, and so on). OTOH, one cannot put any trust in removable
devices (USB/FireWire/PCMCIA/CD-ROMs) anyway, so users can do with
them whatever they want.

So the Ubuntu approach is a bit different: we let hal run as normal
user, do not modify /etc/fstab at all and instead use a program
called 'pmount' (policy mount) that allows normal users to mount
removable devices without an /etc/fstab entries. pmount is now in
Debian sid and contains some documentation about the particular policy
and features. This concentrates the amount of code that runs as root
to a minimum and solves points (1) to (3). Of course hal,
gnome-volume-manager and gnome-vfs2 have to be adapted to work with
pmount, but this work has been done in Ubuntu and it is easy to port
it to Debian proper.

We solved (4) by introducing a new group called 'plugdev'. Every user
who is a member of this group can access hotpluggable devices (digital
cameras, USB drives etc.). pmount can only be executed by members of
this group (it is root:plugdev 750), hal runs in this group to be able
to detect file systems (but it does not run in 'disk'), and udev
assigns the 'plugdev' group to removable devices (static drives remain
in group 'disk').

BTW, we also use 'plugdev' for libgphoto (IIRC Debian uses 'camera'
for that).

This approach has worked great for some months now, and the stable
Ubuntu release 4.10 (Warty Warthog) contains it. The Hoary tree (Sid
equivalent) contains many enhancements and hotpluggable devices work
better than ever before.

I would really like to propagate the same approach to Debian. Sjoerd
seems to be open to it, but since it involves the addition of a new
group and also an udev change, this decision is not confined to the
two of us, so I would like to discuss that before.

Thanks in advance for comments and have a nice day!

Martin

--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntulinux.org
Debian GNU/Linux Developer http://www.debian.org

signature.asc

Marco d'Itri

unread,
Nov 9, 2004, 1:40:15 PM11/9/04
to
On Nov 09, Martin Pitt <mar...@piware.de> wrote:

> We solved (4) by introducing a new group called 'plugdev'. Every user
> who is a member of this group can access hotpluggable devices (digital
> cameras, USB drives etc.). pmount can only be executed by members of
> this group (it is root:plugdev 750), hal runs in this group to be able
> to detect file systems (but it does not run in 'disk'), and udev
> assigns the 'plugdev' group to removable devices (static drives remain
> in group 'disk').

I'm not sure about what I should do as the udev maintainer. The default
udev configuration does not really know for sure if a given device is
removable.

--
ciao, |
Marco | [9103 spz3eQziITnEo]

signature.asc

Isaac Clerencia

unread,
Nov 9, 2004, 3:50:11 PM11/9/04
to
> So the Ubuntu approach is a bit different: we let hal run as normal
> user, do not modify /etc/fstab at all and instead use a program
> called 'pmount' (policy mount) that allows normal users to mount
> removable devices without an /etc/fstab entries. pmount is now in

It's great to have a pmount (policy mount) program that is completely
unrelated to libpmount (portable mount)

;)

Paul Hampson

unread,
Nov 9, 2004, 6:00:19 PM11/9/04
to
On Tue, Nov 09, 2004 at 06:41:40PM +0100, Martin Pitt wrote:
> We solved (4) by introducing a new group called 'plugdev'. Every user
> who is a member of this group can access hotpluggable devices (digital
> cameras, USB drives etc.). pmount can only be executed by members of
> this group (it is root:plugdev 750),

Hmm. What's to stop a user fetching their own version of the pmount
binary? I assume that won't work since they won't have the appropriate
device permissions.

If so, then a+x mode is safe, and directed by Debian Policy (I think. If
not, it's in the Developer's Reference as a good idea).

If not, then there's a nasty security hole at that point.

The rest of it sounds good. I'm not fussed about hal, since I don't
use gnome-volume-manager, but pmount might work better for me than
autofs4, which you can't manually unmount without becoming root. >_<

--
-----------------------------------------------------------
Paul "TBBle" Hampson, MCSE
7th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.H...@Anu.edu.au

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
-----------------------------------------------------------

signature.asc

Henning Makholm

unread,
Nov 9, 2004, 6:50:09 PM11/9/04
to
Scripsit Paul.H...@anu.edu.au (Paul Hampson)

> On Tue, Nov 09, 2004 at 06:41:40PM +0100, Martin Pitt wrote:

> > We solved (4) by introducing a new group called 'plugdev'. Every user
> > who is a member of this group can access hotpluggable devices (digital
> > cameras, USB drives etc.). pmount can only be executed by members of
> > this group (it is root:plugdev 750),

This must be be a typo. Surely such a program would need to be suid
root, i.e. mode 4750 was meant rather than 750. In a Debian package
it should have mode 4754; there is no reason to deny unprivileged
users *reading* the binary as long as they cannot use the suid i-node
to execute it. Policy §10.9, fifth paragraph.

> Hmm. What's to stop a user fetching their own version of the pmount
> binary?

Nothing, anymore than there is something to stop a user compiling such
a program himself. However, the kernel ought to stop said user from
saving his binary in a file owned by root. As long as it's not owned
and suid by root it cannot be used to do privileged operations.

> If so, then a+x mode is safe, and directed by Debian Policy (I think. If
> not, it's in the Developer's Reference as a good idea).

The point of not having a+x is to allow the sysadmin to control who
gets the privilege of using pmount.

--
Henning Makholm "`Update' isn't a bad word; in the right setting it is
useful. In the wrong setting, though, it is destructive..."


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Martin Pitt

unread,
Nov 10, 2004, 5:00:20 AM11/10/04
to
Hi!

Henning Makholm [2004-11-09 23:28 +0000]:


> Scripsit Paul.H...@anu.edu.au (Paul Hampson)
> > On Tue, Nov 09, 2004 at 06:41:40PM +0100, Martin Pitt wrote:
>
> > > We solved (4) by introducing a new group called 'plugdev'. Every user
> > > who is a member of this group can access hotpluggable devices (digital
> > > cameras, USB drives etc.). pmount can only be executed by members of
> > > this group (it is root:plugdev 750),
>
> This must be be a typo. Surely such a program would need to be suid
> root, i.e. mode 4750 was meant rather than 750.

Of course, sorry for that. Like mount, pmount of course needs root
privileges to actually do the mounting. Paul, this also solves your
question: a non-suid pmount cannot do anything useful.

signature.asc

Martin Pitt

unread,
Nov 10, 2004, 5:20:14 AM11/10/04
to
Hi Marco!

Marco d'Itri [2004-11-09 19:32 +0100]:

Our /etc/udev/udev.rules has two new rules directly after the cdrom
and floppy rules:

# put removable IDE/SCSI devices into group 'plugdev' instead of 'disk'
BUS="scsi", KERNEL="sd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", RESULT="1", NAME="%k", MODE="0660", GROUP="plugdev"
BUS="ide", KERNEL="hd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", RESULT="1", NAME="%k", MODE="0660", GROUP="plugdev"

The removable.sh shell script (pasted below) returns whether a device
is actually removable by looking at the "removable" sysfs attribute.
However, this attribute was introduced in the kernel not before 2.6.8.
This is okay for Ubuntu since it ships with 2.6.8.1, and since even
Sarge ships with 2.6.8.1 (at some architectures at least), Etch will
certainly use 2.6.8+ as standard kernel. BTW, I do not want to force
this solution into Sarge, it is too late in the release cycle for such
changes (pmount has an RC bug to prevent Sarge migration).

However, this udev modification is safe even on older kernels; the
script will always return 0 there, which effectively disables above
rules. If devices are not in the plugdev group, but rather in "disk",
the following features will not work:

- pmount will refuse to mount PCMCIA drives since they look like
normal IDE adapters; mounting USB and FireWire devices will still
work, though, because pmount then checks the sysfs ancestry for
USB/FireWire nodes.

- Media checking will not work (e. g. hal will not recognize the
insertion of a card into an USB card reader), because hal does not
run in the "disk" group.

- hal will be unable to detect file systems and device labels on the
removeable devices for the same reason (not being in "disk").

- Users will be unable to partition, format, and label their USB
devices.

So hal/pmount/g-v-m will still be able to mount USB sticks, USB hard
drives, iPods, and so on, but will lack some reasonably important
features.

Martin

----------- /etc/udev/removable.sh -----------------------
#!/bin/sh -e

# print "1" if device $1 is removable, "0" otherwise.
# The "removable" attribute appeared in Linux 2.6.8; this script will always
# print "0" for earlier kernels.

DEV="${1%[0-9]*}"
REMOVABLE="/sys/block/$DEV/removable"

if [ -e "$REMOVABLE" ]; then
cat "$REMOVABLE"
else
echo "0"
fi
exit 0
----------------------------------------------------------

signature.asc

Nikita V. Youshchenko

unread,
Nov 10, 2004, 7:10:08 AM11/10/04
to
> The removable.sh shell script (pasted below) returns whether a device
> is actually removable by looking at the "removable" sysfs attribute.
> However, this attribute was introduced in the kernel not before 2.6.8.
> This is okay for Ubuntu since it ships with 2.6.8.1, and since even
> Sarge ships with 2.6.8.1 (at some architectures at least), Etch will
> certainly use 2.6.8+ as standard kernel. BTW, I do not want to force
> this solution into Sarge, it is too late in the release cycle for such
> changes (pmount has an RC bug to prevent Sarge migration).

AFAIK, Sarge is going to be released with 2.6.8.1

I think keeping pmount out of sarge is a bad idea. As long as pmount works
(it it is *released* with ubuntu, probably it does), and may be useful at
least from command line, why keep it out?

And if, for whatever reason, sarge will not be released for some more time,
maybe some software that will use pmount will also migrate to sarge.

Martin Pitt

unread,
Nov 10, 2004, 7:20:06 AM11/10/04
to
Hi Nikita!

Nikita V. Youshchenko [2004-11-10 14:38 +0300]:


> AFAIK, Sarge is going to be released with 2.6.8.1
>
> I think keeping pmount out of sarge is a bad idea. As long as pmount works
> (it it is *released* with ubuntu, probably it does), and may be useful at
> least from command line, why keep it out?
>
> And if, for whatever reason, sarge will not be released for some more time,
> maybe some software that will use pmount will also migrate to sarge.

For my sake I can close the RC bug and have it in Sarge. I will
support it anyway, Ubuntu and Debian are in sync. I was just unsure
whether there are opinions that it is better to keep it out.

So if anybody does not want pmount to be in Sarge, please speak up now
:-)

Martin

signature.asc

Sjoerd Simons

unread,
Nov 10, 2004, 7:50:04 AM11/10/04
to
On Tue, Nov 09, 2004 at 06:41:40PM +0100, Martin Pitt wrote:
> We solved (4) by introducing a new group called 'plugdev'. Every user
> who is a member of this group can access hotpluggable devices (digital
> cameras, USB drives etc.). pmount can only be executed by members of
> this group (it is root:plugdev 750), hal runs in this group to be able
> to detect file systems (but it does not run in 'disk'), and udev
> assigns the 'plugdev' group to removable devices (static drives remain
> in group 'disk').
>
> BTW, we also use 'plugdev' for libgphoto (IIRC Debian uses 'camera'
> for that).

I personally would prefer two groups. One to give access rights to the raw
device of the removable drive and one to mount them using pmount. I don't like
giving all my programs direct access, just because i'm allowed to pmount a
drive.

Sjoerd
--
Space is to place as eternity is to time.
-- Joseph Joubert

Anand Kumria

unread,
Nov 10, 2004, 8:00:15 AM11/10/04
to

Initially I was going to suggest you'd know because of the bus-type but I
suspect that even that may not be enough (SATA IDE devices: removable or
not; PCI-X cards: removable or not)

I'd assume that all storage can come and go 'at whim'.

Anand
--
linux.conf.au 2005 - http://lca2005.linux.org.au/ - Birthplace of Tux
April 18th to 23rd - http://lca2005.linux.org.au/ - LINUX
Canberra, Australia - http://lca2005.linux.org.au/ - Get bitten!

Paul Hampson

unread,
Nov 10, 2004, 8:00:19 AM11/10/04
to
On Wed, Nov 10, 2004 at 01:25:56PM +0100, Sjoerd Simons wrote:
> On Tue, Nov 09, 2004 at 06:41:40PM +0100, Martin Pitt wrote:
> > We solved (4) by introducing a new group called 'plugdev'. Every user
> > who is a member of this group can access hotpluggable devices (digital
> > cameras, USB drives etc.). pmount can only be executed by members of
> > this group (it is root:plugdev 750), hal runs in this group to be able
> > to detect file systems (but it does not run in 'disk'), and udev
> > assigns the 'plugdev' group to removable devices (static drives remain
> > in group 'disk').
> >
> > BTW, we also use 'plugdev' for libgphoto (IIRC Debian uses 'camera'
> > for that).

> I personally would prefer two groups. One to give access rights to the raw
> device of the removable drive and one to mount them using pmount. I don't like
> giving all my programs direct access, just because i'm allowed to pmount a
> drive.

Do the devices have to be g+w? Surely g+r is enough (or not even
neccesary) for pmount to identify them as pmountable? Although I guess
partitioning would require +w for the user, but in that case the user
needs direct access anyway, and then dialling your USB stick becomes a
distinct possibility.

signature.asc

Marco d'Itri

unread,
Nov 10, 2004, 8:30:07 AM11/10/04
to
On Nov 10, Martin Pitt <mar...@piware.de> wrote:

> Our /etc/udev/udev.rules has two new rules directly after the cdrom
> and floppy rules:
>
> # put removable IDE/SCSI devices into group 'plugdev' instead of 'disk'
> BUS="scsi", KERNEL="sd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", RESULT="1", NAME="%k", MODE="0660", GROUP="plugdev"
> BUS="ide", KERNEL="hd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", RESULT="1", NAME="%k", MODE="0660", GROUP="plugdev"

What about I ship the script in udev (as /etc/udev/scripts/removable.sh)
and your package install the rules file? Or udev provides the rules file
too and your package enables it by creating the symlink?

--
ciao, |
Marco | [9119 prpW76ZT/rZhI]

signature.asc

Martin Pitt

unread,
Nov 10, 2004, 10:50:12 AM11/10/04
to
Hi Marco!

Marco d'Itri [2004-11-10 14:19 +0100]:


> > Our /etc/udev/udev.rules has two new rules directly after the cdrom
> > and floppy rules:
> >
> > # put removable IDE/SCSI devices into group 'plugdev' instead of 'disk'
> > BUS="scsi", KERNEL="sd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", RESULT="1", NAME="%k", MODE="0660", GROUP="plugdev"
> > BUS="ide", KERNEL="hd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", RESULT="1", NAME="%k", MODE="0660", GROUP="plugdev"
>
> What about I ship the script in udev (as /etc/udev/scripts/removable.sh)
> and your package install the rules file? Or udev provides the rules file
> too and your package enables it by creating the symlink?

I was not sure whether it is valid that packages put their scripts
into /etc/udev/rules.d. But I would be fine to leave udev.rules
untouched and have pmount ship /etc/udev/rules.d/z_plugdev.rules (z_
because it must be executed after the standard rules; if it is
executed earlier, CD-ROM and floppy nodes will also be in plugdev,
which is not intended).

If it is okay for you that pmount also ships /etc/udev/removable.sh,
then I can do that as well. In this case the udev package does not
need to be modified at all.

Thanks for your cooperation and have a nice day!

Martin

--

signature.asc

Paul Hampson

unread,
Nov 10, 2004, 6:10:10 PM11/10/04
to
On Wed, Nov 10, 2004 at 04:43:41PM +0100, Martin Pitt wrote:
> Marco d'Itri [2004-11-10 14:19 +0100]:
> > > Our /etc/udev/udev.rules has two new rules directly after the cdrom
> > > and floppy rules:

> > > # put removable IDE/SCSI devices into group 'plugdev' instead of 'disk'
> > > BUS="scsi", KERNEL="sd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", RESULT="1", NAME="%k", MODE="0660", GROUP="plugdev"
> > > BUS="ide", KERNEL="hd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", RESULT="1", NAME="%k", MODE="0660", GROUP="plugdev"

> > What about I ship the script in udev (as /etc/udev/scripts/removable.sh)
> > and your package install the rules file? Or udev provides the rules file
> > too and your package enables it by creating the symlink?

> I was not sure whether it is valid that packages put their scripts
> into /etc/udev/rules.d. But I would be fine to leave udev.rules
> untouched and have pmount ship /etc/udev/rules.d/z_plugdev.rules (z_
> because it must be executed after the standard rules; if it is
> executed earlier, CD-ROM and floppy nodes will also be in plugdev,
> which is not intended).

But don't CD-ROM and floppy devices also need the same sort of pmount
support you're proposing here? After all, you can hot-swap the media in
them, so it seems reasonable to me that they can be pmounted? What's the
rationale for _not_ including these in the pmount infrastructure you're
proposing?

Hmm. Now that I think about it, surely the plugdev group would have to
be given using pam_console so that remote users in the plugdev group
can't remotely stomp on the USB memory stick the local user just put in,
before they could mount it?

In _that_ case, cdrom and floppy strike me as _very_ appropriate for the
same treatment, and the local administrator could add appropriate people
directly to those groups for things like a headless server where someone
whacks in a USB stick, and then wanders back to their laptop to access
it. This would close (to my mind) a security hole in systems where both
local and remote users have access.

signature.asc

Martin Pitt

unread,
Nov 11, 2004, 3:10:15 AM11/11/04
to
Hi!

Paul Hampson [2004-11-11 10:03 +1100]:


> But don't CD-ROM and floppy devices also need the same sort of pmount
> support you're proposing here? After all, you can hot-swap the media in
> them, so it seems reasonable to me that they can be pmounted? What's the
> rationale for _not_ including these in the pmount infrastructure you're
> proposing?

CD-ROMs are fully supported by pmount; hal runs in both floppy and
cdrom group as well, so that media check and file system detection
works.

The only problem are floppies, because there is no sysfs entry for the
floppy device. That means that pmount cannot currently decide that
/dev/fd0 is removable and will refuse to mount it. However, this is
not a big practical problem since legacy floppies are usually present
in /etc/fstab. If a device is already in fstab, pmount <device>
behaves _exactly_ like mount <device>. This fallback allows to use
pmount as a complete replacement of mount in e. g.
gnome-volume-manager.

Maybe there is a misunderstanding here: pmount itself does not care
about the group of a device. pmount decides whether or not the user is
allowed to mount a device by looking at sysfs, not at device
permissions.

The udev mangling is not necessary for pmount, but for hal. Normally,
/dev/hd* and /dev/sd* are assigned to group 'disk'. But access to
group disk is essentially the same as root access, that's why we let
hal run only in group 'plugdev' and assign all removable devices to
group 'plugdev' instead of 'disk.

> Hmm. Now that I think about it, surely the plugdev group would have to
> be given using pam_console so that remote users in the plugdev group
> can't remotely stomp on the USB memory stick the local user just put in,
> before they could mount it?

For Ubuntu we decided not to use pam_console, but put users into
plugdev by default, because some users want to use their USB hard
drives even remotely. However, using pam_console is entirely possible
and in fact this decision is unrelated to the matter of device
permissions. The administrator has to actively put users into plugdev,
pmount will not try to mangle /etc/passwd :-)

Have a nice day!

signature.asc

Martin Pitt

unread,
Nov 11, 2004, 9:30:24 AM11/11/04
to
Hi!

Marco d'Itri [2004-11-10 14:19 +0100]:

I thought over that again. The removable.sh script and the new rules
should not be shipped in pmount, because pmount actually does not care
about the device permissions.

I ship these scripts in the Ubuntu version of hal now, where it fits
much better, because the primary reason for introducing these rules
was to allow hal to read the raw devices. As soon as Sjoerd decides to
adopt the "hal running as normal user" approach, it is sufficient to
adopt the Ubuntu patch to Debian's hal, without caring for any
external dependencies.

Have a nice day!

Martin

--

signature.asc

Paul Hampson

unread,
Nov 12, 2004, 2:00:14 AM11/12/04
to
On Thu, Nov 11, 2004 at 09:07:12AM +0100, Martin Pitt wrote:
> Hi!
>
> Paul Hampson [2004-11-11 10:03 +1100]:
> > But don't CD-ROM and floppy devices also need the same sort of pmount
> > support you're proposing here? After all, you can hot-swap the media in
> > them, so it seems reasonable to me that they can be pmounted? What's the
> > rationale for _not_ including these in the pmount infrastructure you're
> > proposing?

> CD-ROMs are fully supported by pmount; hal runs in both floppy and
> cdrom group as well, so that media check and file system detection
> works.

> The only problem are floppies, because there is no sysfs entry for the
> floppy device. That means that pmount cannot currently decide that
> /dev/fd0 is removable and will refuse to mount it. However, this is
> not a big practical problem since legacy floppies are usually present
> in /etc/fstab. If a device is already in fstab, pmount <device>
> behaves _exactly_ like mount <device>. This fallback allows to use
> pmount as a complete replacement of mount in e. g.
> gnome-volume-manager.

> Maybe there is a misunderstanding here: pmount itself does not care
> about the group of a device. pmount decides whether or not the user is
> allowed to mount a device by looking at sysfs, not at device
> permissions.

Ah, thankyou. I did indeed have it ass-backwards. >_<

_That_ way 'round, I like it. ^_^

signature.asc

Marco d'Itri

unread,
Nov 12, 2004, 5:00:18 AM11/12/04
to
On Nov 10, Martin Pitt <mar...@piware.de> wrote:

> I was not sure whether it is valid that packages put their scripts
> into /etc/udev/rules.d.

It is as long as they discuss it with me. :-)
BTW, I suggest installing the rules files in /etc/udev/ and then
creating a symlink in the rules.d/ directory.

> If it is okay for you that pmount also ships /etc/udev/removable.sh,

Please use /etc/udev/scripts/removable.sh.

--
ciao, |
Marco | [9149 riCXYS//n56m.]

signature.asc

Martin Pitt

unread,
Nov 12, 2004, 5:20:14 AM11/12/04
to
Hi Marco!

Marco d'Itri [2004-11-12 10:42 +0100]:


> On Nov 10, Martin Pitt <mar...@piware.de> wrote:
>
> > I was not sure whether it is valid that packages put their scripts
> > into /etc/udev/rules.d.
> It is as long as they discuss it with me. :-)
> BTW, I suggest installing the rules files in /etc/udev/ and then
> creating a symlink in the rules.d/ directory.

Hmm, the Ubuntu hal package currently places the script directly in
rules.d/ (as with any other *.d file) since I did not want to clutter
up /etc/udev. Is this entirely unreasonable? I can change the Ubuntu
version if necessary.

> > If it is okay for you that pmount also ships /etc/udev/removable.sh,
> Please use /etc/udev/scripts/removable.sh.

For the same reason (not cluttering up /etc/udev) I placed the script
in /usr/share/hal/device-removable.sh. Is this okay as well?

Thanks,

signature.asc

Marco d'Itri

unread,
Nov 12, 2004, 5:40:11 AM11/12/04
to
On Nov 12, Martin Pitt <mar...@piware.de> wrote:

> > BTW, I suggest installing the rules files in /etc/udev/ and then
> > creating a symlink in the rules.d/ directory.
> Hmm, the Ubuntu hal package currently places the script directly in
> rules.d/ (as with any other *.d file) since I did not want to clutter
> up /etc/udev. Is this entirely unreasonable? I can change the Ubuntu
> version if necessary.

Using symlinks allows the user to disable or rearrange the rules.

> > > If it is okay for you that pmount also ships /etc/udev/removable.sh,
> > Please use /etc/udev/scripts/removable.sh.
> For the same reason (not cluttering up /etc/udev) I placed the script
> in /usr/share/hal/device-removable.sh. Is this okay as well?

Probably not, because the script may be run before /usr is available.

--
ciao, |
Marco | [9151 po.VnkGqgKToI]

signature.asc

Sjoerd Simons

unread,
Nov 13, 2004, 7:20:07 AM11/13/04
to
On Fri, Nov 12, 2004 at 10:42:31AM +0100, Marco d'Itri wrote:
> On Nov 10, Martin Pitt <mar...@piware.de> wrote:
>
> > I was not sure whether it is valid that packages put their scripts
> > into /etc/udev/rules.d.
> It is as long as they discuss it with me. :-)
> BTW, I suggest installing the rules files in /etc/udev/ and then
> creating a symlink in the rules.d/ directory.

Is there a way to commit these changes in the udev configuration without the
user needing to reboot. Is it possible to abuse(?) udevstart for this or is
that a bad idea.

Sjoerd
--
A lifetime isn't nearly long enough to figure out what it's all about.

Marco d'Itri

unread,
Nov 13, 2004, 7:30:14 AM11/13/04
to
On Nov 13, Sjoerd Simons <sjo...@spring.luon.net> wrote:

> Is there a way to commit these changes in the udev configuration without the
> user needing to reboot. Is it possible to abuse(?) udevstart for this or is
> that a bad idea.

udevstart should work. Maybe.
Another option is to synthesize the hotplug events.

Anyway, please talk with me before installing udev configuration files
in your package.

--
ciao, |
Marco | [9158 baa53dFtHf5f6]

signature.asc

Martin Pitt

unread,
Nov 13, 2004, 2:50:08 PM11/13/04
to
Hi!

Marco d'Itri [2004-11-12 11:39 +0100]:


> On Nov 12, Martin Pitt <mar...@piware.de> wrote:
> > > BTW, I suggest installing the rules files in /etc/udev/ and then
> > > creating a symlink in the rules.d/ directory.
> > Hmm, the Ubuntu hal package currently places the script directly in
> > rules.d/ (as with any other *.d file) since I did not want to clutter
> > up /etc/udev. Is this entirely unreasonable? I can change the Ubuntu
> > version if necessary.
> Using symlinks allows the user to disable or rearrange the rules.

Correct, I changed this now. The rules file now lives in
/etc/udev/hal-plugdev.rules, with a symlink in rules.d/.

> > > > If it is okay for you that pmount also ships /etc/udev/removable.sh,
> > > Please use /etc/udev/scripts/removable.sh.
> > For the same reason (not cluttering up /etc/udev) I placed the script
> > in /usr/share/hal/device-removable.sh. Is this okay as well?
> Probably not, because the script may be run before /usr is available.

I put it into /etc/udev/scripts/ now.

Thanks for your hints and have a nice weekend!

signature.asc

Thomas Hood

unread,
Nov 14, 2004, 6:20:10 AM11/14/04
to
On Tue, 09 Nov 2004 18:50:39 +0100, Martin Pitt wrote:
> However, I was not satisfied with this solution because of several
> reasons:


[Several excellent reasons]


> So the Ubuntu approach is a bit different: we let hal run as normal
> user, do not modify /etc/fstab at all and instead use a program
> called 'pmount' (policy mount) that allows normal users to mount
> removable devices without an /etc/fstab entries.


All sounds good.

Have you heard that mount's upstream is looking for someone to adopt mount
(and the rest of util-linux)? Interested?

--
Thomas Hood

Reply all
Reply to author
Forward
0 new messages