per-user udev rules subset

gibboris at gibboris at
Tue Sep 29 02:47:35 PDT 2009

I'm new to this list, a bit curious about udev and the upper
layers. I have some questions, not too dumb I wish.

----- re-expliciting to understand myself -----
** What I want : **
I want the ability for a simple user to set ANY action
automatically done according to device events ...
with the "state-of-art" way to think the device events.

** Example : **
"spawn a terminal in the mount-point when a
specific mp3 player is plugged and mounted."
For the "mount" part, udev works well for that.

** Questions / Ways to do : **
But how to get the user execute it's stuff.
1) have a system daemon which execute user's rules
(with this specific user priviledges)
2) have a per-user listener which get informed (by IPC) about the event

** Guesses / Solutions to 1) : **
I first think about the 1) :
I wrote a small uudevd.c (like user-udevd) but it appears that :
- loading a set of rules isn't part of libudev so I would have to
copy a subset of the udev rules parser (eg : remove SYMLINK as we are NOT root,
that's why I put "subset" [rules set] in the subject)
- getting informed about new event isn't much useful as we can't do
anything useful at this level (I know the SERIAL_ID but can't mount) so...
the user rules differ a bit from root's rules which are pure hardware ones.
For a user, I need of course to know the LABEL or SERIAL_ID to perform my
action, but also, if my mp3 player has been correctly mounted by the system
udev rules and if I have the right to access it.

Otherwise I thought about a ~/.udev/rules.d loaded by udev
(or a udevcron {-l,-e} with a ~/.udevtab)
I doubt about whether this idea is good|bad, I don't know why -it hasn't been done yet- ?
(but anyway I would like to be able to do some actions as a user at this level
even if a [[ -d $mountpoint ]] is mandatory)

solution 2 to 1) : 
add the following key name : "USER" to execute PROGRAM or RUN as the given user
-> seems totally dumb : set as root something for a specific user

solution 3 to 1) = displace the question to 2) : give it to a system daemon by dbus :
- then it broadcast to anyone

so a per-user event system :
- can't rely directly upon udev (not enough information / rights)
- shouldn't [...] (not done)

** Guesses / Solutions to 2) : **
DBUS : the need of an IPC system <-> user (=> per-user daemon)
System daemon, can be ringed by udev according to some events, ability for a user
to run per-user dbus-listener of the system daemon...

----- Here come the choice -----
... so I want a user-session configuration file to put, eg :
<the event> <the script> <somes args>

More information about the devkit-devel mailing list