SpaceFM & Udev
Below is an update on what’s happening with SpaceFM (and devmon) with regard to udev, udisks2, and related matters. None of this has hit release yet, but some of it is currently available on github for those who would like to help with early testing, or just give it a try.
Udisks is a layer that sits between udev and applications – it is supposed to make it easier for applications and user scripts to manipulate disks, detect device changes, mount removable devices without a root password, etc. Unfortunately this component is developed almost exclusively by Red Hat Gnome developers who are increasingly making it less than helpful. I’ve made no secret of what I think of udisks2. As soon as I saw it, I started exploring ways to remove it.
The next release of SpaceFM, which is currently available on github in the ‘next’ branch, replaces udisks with internal support for libudev, thus allowing SpaceFM to go directly to udev for its device manager needs. This includes three new custom components:
- A custom udev monitor has been added which connects to a udev socket. This monitor lets SpaceFM know when a device has a been added or removed, and when device properties have changed. Previously, SpaceFM used the udisks monitor function for this.
- A custom mount monitor has been added which monitors the system’s mount points and alerts SpaceFM to changes. This lets SpaceFM know when a device has been mounted or unmounted, even if it didn’t initiate the action. Because udev does not report these events, a separate monitor is needed which ties into /proc. Previously, SpaceFM used udisks for this – udisks included mount changes in its monitor function.
- Device information functions have been added to SpaceFM so it can use udev functions to lookup information about a device, such as whether the device is internal, removable, or optical, what media it contains or supports, what filesystem is on the device, the size of the device, etc. These functions were added using code excerpts from the udisks 1.0.4 sources, with a few fixes and improvements, and also some simplification. Previously, SpaceFM ran the udisks command line tool to obtain device information. However, the udisks2 command line tool is crippled – for example, you can no longer use it to determine if a drive is optical or not, what media it contains, as well as other deficiencies.
In initial tests, this code has been running well. There aren’t many noticeable changes – the new code duplicates most of what udisks used to provide. There is a little less information provided about special devices like encrypted drives, but SpaceFM did not use this information internally, it only displayed it in the device properties, and even then it was minimal. Another difference is that SpaceFM does not poll devices as udisks sometimes did. Some polling could be added if necessary, but thus far this hasn’t been an issue, even with my less-than-new hardware.
With these changes, SpaceFM doesn’t use udisks for anything except mounting and unmounting devices without a root password needed. As before, it runs the udisks command line tool to do so, and it now supports both udisks v1 and v2 for this. Also, two new options have been added to allow the user to set custom mount and unmount commands:
Thus, any use of udisks is optional, although still somewhat required if you want to mount without root. Mounting and unmounting without root cannot be handled internally by SpaceFM because something needs to run as root to do so (in udisks’s case, it runs a root daemon).
If you’d like to give the ‘next’ branch SpaceFM a try, just check the README for instructions (see the BUILD NEXT section) – just a few simple commands. Note that there are two new build dependencies for this version: libudev0 and libudev-dev
Looking Ahead
Because I don’t want udisks to be required at all (and because I don’t even want it installed on my system), I’m working on a small replacement tool for this. Basically, this will be a functional replacement for the udisks v1 command line tool.
Here are some design goals for this new tool (which doesn’t have a name yet called udevil):
- It will use a combination of the udisks v1 and v2 command line usage, so it can emulate both. It will provide a limited set of functions, such as mount, unmount, monitor, info, and enumerate. Thus scripts like devmon will be able to use this tool rather than udisks. (The udisks APIs will not be provided, however, just the command line.)
- Its output will emulate udisks v1, so scripts designed to use udisks v1, such as devmon, will be able to use this tool instead.
- Because there is no real need for a daemon, root access will likely be done by setting the UID bit, which basically means the program can be run as root without the root password, relying on internal authentication and security checks. This allows you to control who can execute the program, and thus who can mount devices, by setting permissions and groups, rather than all the complexities (and bugs) of policykit/consolekit. Some additional security options will be available in a configuration file. Although some people have a knee-jerk reaction to setting UID, as it is sometimes used poorly, it is a legitimate method (for example, the passwd program uses it), and this is a perfect use for it. If done well, it will provide security without the overhead of a daemon. One of the biggest problems with udisks is its use of policykit and consolekit – many users disable the security rules just to get it working at all, which obviously isn’t helpful. IMO, these solutions create more problems than they solve. You can read more about suid in this article.
- It will optionally be able to use udisks v1 or v2 to perform mounting, in case a user prefers to have the udisks daemon handle root mounting, in which case the UID bit can be unset, but still wants to use this tool with a script like devmon.
- I would like this tool to extend on udisks abilities in a few areas, including the ability to specify a custom mount point when mounting, and the ability to mount ISO files as a non-root user.
Thus this small tool will replace all need for udisks, policykit, devicekit, and consolekit, for those who don’t want them installed. This tool will allow SpaceFM to be completely free of udisks and all the associated *kits, but will not be required. You will be able to use udisks v1, udisks v2, this tool, or any other program or script you want to mount and unmount devices in SpaceFM. For future versions of devmon, you will be able to use just this tool without any need for udisks and the *kits, or you can use udisks v1 alone, or use a combination of udisks v2 and this tool.
I already have a working prototype which nicely emulates udisks v1 monitor and info functions, including a mount monitor – this protoype was also part of SpaceFM’s recent changes. This prototype won’t be released, but it will be used to build a release version.
This tool aims to provide a lightweight replacement for udisks, particularly for those running lightweight desktops, and for situations where the use of the *kits is overkill and creates problems. Like anything, it will have its limitations, but I think another choice in this area will be helpful.
UPDATE May 22 2012:udevil is now available for testing
8 Comments
Sorry, the comment form is closed at this time.
IgnorantGuru's Blog 
I wonder if working via sudo could also be a option.
Well, the idea here is the need for a solution to mount without a password, as in clicking on a device in a file manager, or using devmon to automount as a user. If you’re using sudo, you could just run mount directly, or run this tool as root using sudo. Somehow it has to be run as root – doesn’t matter how. But using sudo involves typing a password. It can certainly work that way if you want the password – similar to running udisks with sudo to bypass policykit restrictions.
Actually, one can specify via sudoers that a certain command can be run without requesting a password first. I just felt it worth a mention as an alternative to suid, tho suid is more likely to work across various systems.
It’s a good idea -users who want to use sudo for this could do so and turn the suid bit off.
Why not use pmount instead of mount?
Maybe I should elaborate more.
Rox-filer uses pmount so user can mount/unmount without giving root password.
In combination with this udev script (used in antiX, but borrowed from Arch) called 99-usbstorage.rules
KERNEL!="sd*[1-9]*", GOTO="exit" # Import FS infos SUBSYSTEMS=="usb", IMPORT{program}="/sbin/blkid -o udev -p %N" # Get a label if present, otherwise specify one SUBSYSTEMS=="usb", ENV{ID_FS_LABEL}!="", ENV{dir_name}="%E{ID_FS_LABEL}" SUBSYSTEMS=="usb", ENV{ID_FS_LABEL}=="", ENV{dir_name}="usb-%k" # Global mount options SUBSYSTEMS=="usb", ACTION=="add", ENV{pmount_options}="--noatime" # File system specific mount options to avoid auto probing SUBSYSTEMS=="usb", ACTION=="add", ENV{ID_FS_TYPE}=="ntfs|vfat", ENV{pmount_options}="%E{pmount_options} --umask 007 --charset utf8" SUBSYSTEMS=="usb", ACTION=="add", ENV{ID_FS_TYPE}=="ntfs", ENV{pmount_options}="%E{pmount_options} -t ntfs-3g" SUBSYSTEMS=="usb", ACTION=="add", ENV{ID_FS_TYPE}=="vfat", ENV{pmount_options}="%E{pmount_options} -t vfat" SUBSYSTEMS=="usb", ACTION=="add", ENV{ID_FS_TYPE}=="ext2", ENV{pmount_options}="%E{pmount_options} -t ext2" SUBSYSTEMS=="usb", ACTION=="add", ENV{ID_FS_TYPE}=="ext3", ENV{pmount_options}="%E{pmount_options} -t ext3" SUBSYSTEMS=="usb", ACTION=="add", ENV{ID_FS_TYPE}=="ext4", ENV{pmount_options}="%E{pmount_options} -t ext4" # Mount the device SUBSYSTEMS=="usb", ACTION=="add", RUN+="/bin/su antiX -c '/usr/bin/pmount $env{pmount_options} /dev/%k /media/%E{dir_name}'" # Clean up after removal SUBSYSTEMS=="usb", ACTION=="remove", ENV{dir_name}!="", RUN+="/usr/bin/pumount /dev/%k" # Exit LABEL="exit"once device is plugged in, in automatically appears in rox under /media and unmount (via pumount) in rox safely unmounts as user as well.
Thanks for the info. I’ve heard of pmount but haven’t tried it – I’ll look into it. The fewer wheels I need to reinvent, the better. Also, from what you describe, it sounds like pmount should already work with the new version of spacefm (currently in the next branch) – you can set custom mount and unmount commands in this version. If so, there is no need for udisks.
Glad to see this!
I tied udev into my own scripts, it was far more work than I would have liked to have static mount points (/media/usb0-100) for read-only, easy findability, cross familiarity for users with bsd (/mnt/usb0-100, actually I didn’t get round to fixing that, linking failed) and working on a read-only root filesystem with custom mount options.
It was nice, though it still annoys me that Linux has gone windows style of years ago that windows was highly criticised by unix users for in not giving any clue how long a copy to a usb1 port will take. Linux also seems to take it’s time to get started sometimes, may I add, I suggest looking at OpenBSDs code there even if it does look like it stops and starts when in fact that’s just the indicator.
Now I hit ok to install and switch to udisks2 and whilst I used to have both mount point and device name in Nautilus (mount point didn’t appear in thunar anyway) which was cool, the mount point has now dissapears after appearing for a second along with my tie in to unmount via sudo, grrr! The parts I added were running as an unpriviledged user, simply because, why not. I might have to change that now or look into fine graining rather than others unmount that polkit says is unauthorised, or maybe use spacefm. I haven’t the time for this sh*t really though.
OpenBSD has always been very nice to use and Linux has mostly been very nice to use, lately linux and desktop technologies, binary config files, multiple random config locations, lack of documentation except for Google, disregard for the commandline and customisation and not follwoing the unix philosophy of simple tools doing a single job well and allowing more than the sum of it’s parts is annoying me.