Hi Stef, >From what I uinderstand, udev is to low-level. My 1st goal is to get all devices (known and unknown) automounted. Then, to let a user spawn any action for any block device event (added, removed, mounted, unmounted)
1) I have set all the rules for my known hardware in the fstab
so users have the right to mount it.
2) Here the devkit-disks-trigger (attachment) plays the role of ivman,
nothing root happens : each user can set a configuration file and launch
devkit-disks-trigger dbus listener at session startup so devices can be
automounted (and eg, a terminal spawn in the mountpoint).
3) Then for the unknown devices, I will use the udev rule (I saw somewhere in
the
/usr/share/udev) which create a mount point (the mount point dir name
can be numbered or can be the label of the partition, ...).
It system-wide but then the users can also be warned about a new device mounted
by devkit-disks-trigger as in 2).
In my case, I don't really mind about mountpoint path, I just want the ability
for a user to go there quickly so I want to have the freedom to launch the
terminal
in the mountpoint, set a variable, create a symlink, do a rsync, ...
I'm quite sure you may find it useful with a config like :
[my_device]
IdLabel=mypictures
# choice 1 : it's configured in fstab to let a user mount it
DeviceAdded=mount %device_file my stuff like I want
DeviceMountPaths=/mnt/pictures #or /home/user/media/mypictures
DeviceMounted=mirage /mnt/pictures
# choice 2 : the mount part is done by root, or udev
# so we only do stuff at post-mount time
DeviceMounted=mirage %device_mount_paths
(but ! the %device_mount_paths doesn't works (currently) as
DeviceMounted event is analysed if we have specified WHICH
mount point to check, we have to know it before)
I'm in the process to correct that but it means the current version
doesn't permit the following workaround :
(have_common_mount_path test even if DeviceMountPaths is NULL)
[nonworkaround]
# triggered whenever a mount happens
DeviceMounted=/tmp/myhelper.sh
(Look at the sample configuration file in the archive)
The main limitations of the attached program are currently :
- the unability to get the props from the mount_paths in the callback
of mount-{added,removed} and the fact that the mountmonitor doesn't give an
object_path.
- my unability to integrate the code in the devkit-disks source directory
which makes the current code bundle some struct already defined elsewhere.
(many hours attempting to understand why "make" can't stop throwing bunch
of "already defined", "not defined" errors and playing with #ifndef
GUARD_HEADER bored
me far enough)
===> tools/devkit-disks.c and src/devkit-disks-daemon.c should probably define
some of their
struct in a common .h (what about lib/device-property.h ?)
(particularly: DeviceProperties, collect_props, device_properties_get,
device_properties_free)
I didn't think about polkit and multiseat (I need per-user udev rules which in
fact
a per-user devkit-disks --monitor-and-trigger), as shared devices, imply a root
definition
of groups and behavior (system udev or polkit) and I don't want to deal with
that now :)
Let me know if you have any advice, criticisms, ...
Raph
On Tue, Oct 13, 2009 at 07:56:47AM +0200, Stef Bon wrote:
> Hello,
>
> your idea of per-user udev subset is great. I've been working on a
> construction
> which makes access to network- and hardware resources available in a
> directory
> in your homedirectory and not a foreign place like /mnt or /media.
>
> The latest construction is using the automounter and a fuse module I
> call fuse-workspace
>
> The latest mirrors a special directory under the directory where
> it's mounted.
> Via configuration it's possible to make symbolic links look like
> normal directories.
> In this case for example a symbolic link to the hardeware in /media
> (mounted by HAL)
> or in /mnt (by the automounter) is presented as directory, making it
> look like
> hardware is direct available in the users homedirectory.
>
> This construction works very well, but has problems with HAL and
> thus my desktop KDE.
> HAL uses a global setting for the mountpoint, which is thus the same
> for all user.
> If I want that the user logging in, working with KDE to work with
> the directory in
> the homedirectory where the hardware device is also available, I
> have to alter the mountpoint
> parameter in the HAL settings for this device. But then this is
> changed for all the users working
> on this machine (and with multiseat this is possible), and you don't
> want that!
>
> The only sollution is per-user rules.
>
> I do not understand your goal exactly, and the reason that you want
> per-user rules is maybe
> another I want it.
>
>
> Stef Bon
devkit-disks-trigger.tar.gz
Description: Binary data
_______________________________________________ devkit-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/devkit-devel
