udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

IgnorantGuru · 2012-05-25 02:12:54

udevil, a command line tool for mount related tasks, was developed as an alternative to udisks. Similar to pmount in some ways, but more flexible and capable, it allows users to mount devices without a password. It can also monitor udev to report device changes and produce info on a device, using output which emulates the udisks v1 command line tool. It can also optionally mount network URLs (eg smb:// nfs://) and ISO files, and accepts custom mount points. udevil only depends on libudev and glib2 - NO udisks, gvfs, fuse, consolekit, policykit, devicekit, etc., but can coexist with all or any of these, including pmount.

udevil can be used as a udisks replacement in SpaceFM (forum), and soon, devmon (forum). It can also be used directly - just prefix a normal mount or umount command with 'udevil'.

This is a test release.. Please read the initial release announcement. And you can see the usage examples.

udevil aims to make configuration simpler and also more flexible. udevil is a tool, not a toy - the admin is given real power in terms of deciding what can be mounted by whom, where, and with what options. This does mean care needs to be taken when configuring it - please read the comments in udevil.conf.

udevil doesn't use policykit for authentication (as this mechanism is IMO broken and often a source of problems more than anything else). It can be configured to limit use based on a number of things, such as users, groups, fstypes, devices, networks, etc.

udevil also has some advanced extensible features, such as allowing you to hook scripts into its behavior. For example, if you do want to check for a consolekit session, you could write a script to do so and have udevil run it via its validate_exec setting (see udevil.conf). consolekit being such a pain, I don't recommend that, but it should be possible. You can add just about any validation mechanism you like, in addition to udevil's built-in validation scheme.

The 'next' branch of SpaceFM (what will be the next release version after the current 0.7.6) now uses udevil automatically if installed. Or if you're using SpaceFM 0.7.6, you can set the mount and unmount commands manually (eg udevil mount -o %o %v). If you want to use udevil with devmon, you can wait for the next release, hack the script changing /usr/bin/udisks to /usr/bin/udevil, or create a link (ln -s /usr/bin/udevil /usr/bin/udisks).

udevil can be found on the homepage and is available in ~~the AUR as udevil-git~~ [community], and the next branch is available in the AUR as udevil-git. You're welcome to discuss issues here or report them for tracking, etc.

I don’t typically use every filesystem or network that udevil handles. If you are an experienced user of a filesystem or network filesystem, I would appreciate feedback on what you think default and allowed options should be for that filesystem. The default udevil.conf contains minimal options to keep things secure and provide basic functionality, but can use some additional options in some areas.

Thanks for testing.

Last edited by IgnorantGuru (2012-11-15 23:43:36)

ninian · 2012-05-25 13:34:29

Thank you very much for your work on this. From a quick scan through the links, it looks as though you have built a lot of functionality into udevil (like the name, by the way), and I will look forward to testing it out properly. Onward and upward!

PS: It's almost a shame that udevil can't be a daemon - excusing the pun!

Last edited by ninian (2012-05-25 13:46:55)

anonymous_user · 2012-05-25 18:04:37

ninian wrote:

PS: It's almost a shame that udevil can't be a daemon - excusing the pun!

So does udevil have to run everytime you want to mount a device? It doesn't automount?

ninian · 2012-05-25 18:28:38

anonymous_user wrote:

So does udevil have to run everytime you want to mount a device? It doesn't automount?

$ udevil --help =>

For automounting with udevil run 'devmon --help'

http://ignorantguru.github.com/udevil/ =>

... udevil can also replace udisks in the SpaceFM file manager and the devmon automounting daemon (devmon is included with udevil).

anonymous_user · 2012-05-25 18:43:52

Ok I forgot udevil replaces udisks not devmon. Thanks.

swanson · 2012-05-25 19:02:25

How du you mount iso's and img's? I've tried;

 udevil mount a-takemht.iso
udevil: error: relative argument 'a-takemht.iso' not permitted
udevil mount "/home/mrmedia/VIDEO/a-takemht.iso"
udevil: error: cannot stat /home/user/VIDEO/a-takemht.iso: Value too large for defined data type
udevil mount -t iso9660 -o loop -b /home/mrmedia/VIDEO/a-takemht.iso /home/mrmedia/
udevil: error: cannot stat /home/mrmedia/VIDEO/a-takemht.iso: Value too large for defined data type

IgnorantGuru · 2012-05-25 20:59:07

swanson wrote:

How du you mount iso's and img's? I've tried;

 udevil mount a-takemht.iso
udevil: error: relative argument 'a-takemht.iso' not permitted
udevil mount "/home/mrmedia/VIDEO/a-takemht.iso"
udevil: error: cannot stat /home/user/VIDEO/a-takemht.iso: Value too large for defined data type
udevil mount -t iso9660 -o loop -b /home/mrmedia/VIDEO/a-takemht.iso /home/mrmedia/
udevil: error: cannot stat /home/mrmedia/VIDEO/a-takemht.iso: Value too large for defined data type

Thanks - I haven't seen that 'Value too large for defined data type' - it could be a 64 bit file size is needed on the stat, I'll look what I used. You might try a smaller ISO file to confirm that's the issue, but it sounds like it.

IgnorantGuru · 2012-05-25 21:01:18

anonymous_user wrote:

Ok I forgot udevil replaces udisks not devmon. Thanks.

udevil 0.2.1 is available, which includes the updated devmon 1.1.0 (which will use udevil automatically if installed). You can read the details here. Any bugs for devmon can be posted here or to the udevil issues, since it is part of udevil now.

swanson · 2012-05-25 21:08:50

The ISO's I have are about 4,3 GB.

IgnorantGuru · 2012-05-26 15:45:35

swanson wrote:

The ISO's I have are about 4,3 GB.

This should now be corrected in the next branch (what will be 0.2.2):
https://github.com/IgnorantGuru/udevil/issues/1

You have the dubious honor of the first bug.

Also, relative arguments are now permitted. Your mount command was correct:

udevil mount xxx.iso

(You need to add 'file' to allowed_types in udevil.conf for that to work.)

swanson · 2012-05-26 17:37:13

I had 'file' in the config. I'll try the new version! Thx!

swanson · 2012-05-26 17:45:01

Tested! Works like a charm! It's a very nice replacement for cdemu. Only thing, for those who use systemd, /media is taken for tmp use and can't be used by others.

Thanks for the nice work!

avx · 2012-05-26 20:24:35

I see you've got support for {smb,ftp,nfs}://, how about adding ssh:// via sshfs?

swanson · 2012-05-26 20:45:18

works very well with qtfm, not yet with thunar. It's a mistery.

ninian · 2012-05-26 22:41:10

My tests have gone well ... only a couple of snags I've found so far:
- Installing the udevil-git package overwrites an existing /etc/udevil/udevil.conf; if it exists, could the new one be installed as /etc/udevil/udevil.conf.pacnew?
- If you set allowed_media_dirs = /run/media/$USER, the directory is not automatically created by udevil; if you create it manually (# mkdir -p /run/media/user) then udevil works, but the directory is lost on reboot (as far I can tell)

swanson · 2012-05-26 22:52:39

Seems that /run/media works ok without $USER.

IgnorantGuru · 2012-05-27 01:09:50

avx wrote:

I see you've got support for {smb,ftp,nfs}://, how about adding ssh:// via sshfs?

Yeah there are a lot of possibilities there. At some point I'm going to look over lufs, etc. and see how the various protocols could be integrated. smb, nfs, and ftp are a starting point but I'd like the interface to handle more.

IgnorantGuru · 2012-05-27 01:19:23

ninian wrote:

My tests have gone well ... only a couple of snags I've found so far:
- Installing the udevil-git package overwrites an existing /etc/udevil/udevil.conf; if it exists, could the new one be installed as /etc/udevil/udevil.conf.pacnew?

Thanks for letting me know - definitely shouldn't overwrite. There was something in the makefile unusual with this - I'll need to look it over and how that can work better on Arch. Feel free to advise me if someone finds what's up with it, but I'll take a look before the next release. Also, this reminds me that an upgrade may turn suid back on if you turned it off, which I don't want to be the case either.

- If you set allowed_media_dirs = /run/media/$USER, the directory is not automatically created by udevil; if you create it manually (# mkdir -p /run/media/user) then udevil works, but the directory is lost on reboot (as far I can tell)

udevil doesn't create the media directory(s) - they must exist, and for good security should be owned and writable by root only. I'm not sure what the convention is on /run/media/$USER but I'll take a look - since it's in /run it's more dynamic. If you have an idea of what you think the behavior should be let me know. Also keep in mind that with udevil you can use any media directories you configure, so you don't have to follow the system default.

Thanks for the testing.

EDIT: One other note - I said udevil won't create media directories. However it will automatically create mount points within a media directory, including ones you specify. So for example, you can run this:

udevil mount /dev/sr0 /media/test

and the test directory will be created if it doesn't exist - unlike mount, you don't need to create it first. But /media will not be created if missing.

Last edited by IgnorantGuru (2012-05-27 01:28:24)

IgnorantGuru · 2012-05-27 01:22:36

swanson wrote:

works very well with qtfm, not yet with thunar. It's a mistery.

I'm not familiar with qtfm or what you mean by working. Just want to note that udevil is not a complete udisks replacement. It emulates much of the command line tool, but does not provide the udisks library, dbus interface, etc. So most programs that depend on udisks (such as thunar) will not accept udevil as a udisks replacement. spacefm is unusual in this regard - it has udev support built-in now (device monitoring, etc), and lets you set any commands for mounting - hence the easy integration with udevil.

swanson · 2012-05-27 03:40:27

I meant just that, qtfm immediately sees the mountpoint, thunar does not.

More findings; /media works on my systemd setup, so my statement earlier was wrong.
/run/media isn't created at boot and not by udevil either on my setup. /run is there but no /media dir in it. And subsequently no /$USER in that. Maybe a quirk on my steup or a quirk in Arch?

I don't see this as problems, just reporting observations.

PS. One can use a Thunar UCA like; udevil mount %f ; thunar /media/%n
depending on your mountpoint.
And udevil umount %f works in the /media/"mountpoint.img" (the dir)

Really like this compared to cdemu which was poorly maintained and had to be reinstalled every major kernel update. I ditched it a while ago so with udevil I'm happy!

Last edited by swanson (2012-05-27 06:22:41)

ninian · 2012-05-27 13:25:28

IgnorantGuru wrote:

udevil doesn't create the media directory(s) - they must exist, and for good security should be owned and writable by root only. I'm not sure what the convention is on /run/media/$USER but I'll take a look - since it's in /run it's more dynamic. If you have an idea of what you think the behavior should be let me know.

Well, I'll not sure what should happen about the creation of /run/media/USER, but I'll cop out and tell you what udisks2 (ahem) does:
If /run/media/USER or even /run/media doesn't exist, then the command 'udisksctl mount --block-device /dev/sdxn' will create either or both as required, with the following ownership and permissions:
/run/media : root:root drwxr-xr-x
/run/media/USER : root:root drwxr-x---
and the media filesystem gets mounted at:
/run/media/USER/LABEL: USER:users drwx------
(of course, when 'udisksctl unmount --block-device /dev/sdxn' is used to unmount, only /run/media/USER/LABEL is removed; /run/media/USER remains.)
This certainly is convenient behaviour, but whether you think this would be good behaviour for udeveil is another matter!
At the moment, I'm just putting 'mkdir -p /run/media/USER' in my /etc/rc.script (on Arch, /run is now automatically mounted as a tmpfs).

I've also found some inconsistencies in the way that udevil reports its output, compared to udisks:
udisks2 sends successful output to stdout and errors to stderr, but udevil seems to send everything, good or bad, to stderr
udisks2 reports 'Unmounted <device>' if successful, but udevil reports nothing at all
When mounting an optical disk, udevil also outputs 'mount: block device /dev/sr0 is write-protected, mounting read-only' to stderr, as well as 'Mounted /dev/sr0 at /run/media/me/LABEL' to stderr. Is this extra line really necessary or could it be suppressed via the udevil.conf in some way?
For scripts, it would be good if udevil could output normally to stdout, and errors to stderr, as udisks2 does. Would seem more logical and consistent.
(The reason I discovered these anomalies is that I maintain my own un/mounting script to keep it really easy for users I support. I capture the command's output in a variable and send it to notify-send if the return code is zero.)

Nevertheless, udevil is a GREAT development!

Last edited by ninian (2012-05-27 13:27:08)

acvar · 2012-05-27 15:04:15

Devmon + udevil is mounting properly, but it is not unmounting. Udevil attempts to unmount a device in /dev that does not exist since it has allready been removed.

Last edited by acvar (2012-05-27 15:05:43)

swanson · 2012-05-27 16:16:25

udevil works ok for iso/img's to unmount.

IgnorantGuru · 2012-05-27 18:27:42

udevil 0.2.3 is available - see changes

IgnorantGuru · 2012-05-27 18:47:36

ninian wrote:

Well, I'll not sure what should happen about the creation of /run/media/USER, but I'll cop out and tell you what udisks2 (ahem) does:
If /run/media/USER or even /run/media doesn't exist, then the command 'udisksctl mount --block-device /dev/sdxn' will create either or both as required, with the following ownership and permissions:
/run/media : root:root drwxr-xr-x
/run/media/USER : root:root drwxr-x---
and the media filesystem gets mounted at:
/run/media/USER/LABEL: USER:users drwx------
(of course, when 'udisksctl unmount --block-device /dev/sdxn' is used to unmount, only /run/media/USER/LABEL is removed; /run/media/USER remains.)

Thanks for looking into it. Actually the permissions on /run/media/$USER are drwxr-x---+, the plus indicating that a acl is used:
# file: run/media/USER
# owner: root
# group: root
user::rwx
user:USER:r-x
group::---
mask::r-x
other::---

udevil 0.2.3 now emulates udisks2 behavior wrt /run/media/$USER - it will be created on demand and the acl set. If setfacl fails, it will fallback to rwxr-xr-x, as rwxr-x--- wouldn't allow the user to access it. Let me know if that solves the issues you had.

Also, note the following note added to udevil.conf under allowed_media_dirs:

# NOTE: If you want only the user who mounted a device to have access to it
# and be allowed to unmount it, specify /run/media/$USER as the first
# allowed media directory.

/media is still the default in udevil.conf. If /media doesn't exist, it uses /run/media/$USER.

And, in case you need to change the location of setfacl:

# setfacl_program = /usr/bin/setfacl

You can see the newest udevil.conf here.

I've also found some inconsistencies in the way that udevil reports its output, compared to udisks:

udevil loosely emulates udisks v1 output, not udisks2. I won't be following udisks2 for most things, because the developers keep changing it at random, and warn that the output may be inconsistent.

udisks2 reports 'Unmounted <device>' if successful, but udevil reports nothing at all

Thus emulating udisks1. I wouldn't mind adding 'Unmounted...', but would it be useful? Also note that you can hook into success_exec in udevil.conf for scripts. You can also get additional output using --verbose.

When mounting an optical disk, udevil also outputs 'mount: block device /dev/sr0 is write-protected, mounting read-only' to stderr, as well as 'Mounted /dev/sr0 at /run/media/me/LABEL' to stderr. Is this extra line really necessary or could it be suppressed via the udevil.conf in some way?

The 'mount: block device /dev/sr0 is write-protected' is output by mount - you can avoid that message by adding the ro option to /dev/sr0's entry in fstab, or if not present, by adding 'ro' to the default options for the fstype (eg iso9660) in udevil.conf. udevil doesn't censor mount's output.

For scripts, it would be good if udevil could output normally to stdout, and errors to stderr, as udisks2 does. Would seem more logical and consistent.

Agreed. I'll likely change that. Thanks again for the details.

Also, udevil.conf should no longer be overwritten by the AUR package. The first time you install the new package, it may copy your udevil.conf to pacorig - not sure. In any event, make a backup before testing.

Last edited by IgnorantGuru (2012-05-27 19:05:53)

Arch Linux

#1 2012-05-25 02:12:54

udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#2 2012-05-25 13:34:29

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#3 2012-05-25 18:04:37

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#4 2012-05-25 18:28:38

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#5 2012-05-25 18:43:52

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#6 2012-05-25 19:02:25

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#7 2012-05-25 20:59:07

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#8 2012-05-25 21:01:18

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#9 2012-05-25 21:08:50

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#10 2012-05-26 15:45:35

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#11 2012-05-26 17:37:13

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#12 2012-05-26 17:45:01

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#13 2012-05-26 20:24:35

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#14 2012-05-26 20:45:18

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#15 2012-05-26 22:41:10

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#16 2012-05-26 22:52:39

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#17 2012-05-27 01:09:50

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#18 2012-05-27 01:19:23

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#19 2012-05-27 01:22:36

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#20 2012-05-27 03:40:27

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#21 2012-05-27 13:25:28

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#22 2012-05-27 15:04:15

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#23 2012-05-27 16:16:25

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#24 2012-05-27 18:27:42

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

#25 2012-05-27 18:47:36

Re: udevil - mount without password, monitor udev [SpaceFM, devmon, CLI]

Board footer