A very lightweight volume manager

jerryluc · 2009-04-19 20:44:06

@dimigon: thanks for the clear up. I've installed the git-version, and tried what you said. My external hdd got automounted by skvm, and the i umounted it ("umount /dev/sdb1"). But the directory didnt get deleted.

dimigon · 2009-04-19 23:57:03

jerryluc wrote:

@dimigon: thanks for the clear up. I've installed the git-version, and tried what you said. My external hdd got automounted by skvm, and the i umounted it ("umount /dev/sdb1"). But the directory didnt get deleted.

Hi, make sure the directory is not being used when you eject the drive, either by being already mounted for another device or you are cd-ed into that directory at the moment of ejecting (in which case umounting would fail). Either way, you can take a look at the system logs (cat /var/log/messages.log | grep -i skvm) for a warning message caused by a failing rmdir(2) similar to the following

Apr 15 15:54:15 scron-gr ./skvm[13139]: skvm.c:288: Device or resource busy

In any way, does it do this for a particular volume or do you have this problem generally with any mounteable device?

Last edited by dimigon (2009-04-20 00:05:12)

Heller_Barde · 2009-04-20 11:35:03

hai I like the idea of that program a lot, but it has one major feature missing for me (which i'd try to implement myself, don't worry ):

would it be possible to call an external program as soon as a device is detected and depending on the return state of that program decide whether this device should be mounted (or not). This external program could default to /bin/true for current behaviour (afaict) but could for example call a dialog or a notification of some sort, just whatever one would specify in some configuration file.

what do you think, would that be very hard to weave into your current code? if not, i'd try to write a patch for this lovely program.

cheers Barde

dimigon · 2009-04-20 12:05:56

Heller_Barde wrote:

hai I like the idea of that program a lot, but it has one major feature missing for me (which i'd try to implement myself, don't worry ):
would it be possible to call an external program as soon as a device is detected and depending on the return state of that program decide whether this device should be mounted (or not). This external program could default to /bin/true for current behaviour (afaict) but could for example call a dialog or a notification of some sort, just whatever one would specify in some configuration file.
what do you think, would that be very hard to weave into your current code? if not, i'd try to write a patch for this lovely program.
cheers Barde

Hello! That is a brilliant idea! All you need to change is function "device_added" near line 266 where you see do_mount(device) < 0 ? ... etc etc if you wrap and 'if' around it then it will mount the device only if the 'if' is true which should depend on the return state of the program that you called. Look into how I use g_spawn_sync(...) which calls another program near line 540. You can also use fork-exec but you have to take care of a couple of things. As regards the configuration file, well you can add the parsing of that anywhere in the code and parse it at start-up or everytime the daemon receives a SIGHUP. Good luck!

Last edited by dimigon (2009-04-20 12:10:13)

Heller_Barde · 2009-04-20 12:07:09

dimigon wrote:

Hello! That is a brilliant idea! All you need to change is function "device_added" near line 266 where you see do_mount(device) < 0 ? ... etc etc if you wrap and 'if' around it then it will mount the device only if the 'if' is true which should depend on the return state of the program that you called. Look into how I use g_spawn_sync(...) which calls another program near line 540. You can also use fork-exec but you have to take care of a couple of things. Good luck!

I will try that tonight, I'll report back on my success

dimigon · 2009-04-20 12:26:41

Heller_Barde wrote:

dimigon wrote:
Hello! That is a brilliant idea! All you need to change is function "device_added" near line 266 where you see do_mount(device) < 0 ? ... etc etc if you wrap and 'if' around it then it will mount the device only if the 'if' is true which should depend on the return state of the program that you called. Look into how I use g_spawn_sync(...) which calls another program near line 540. You can also use fork-exec but you have to take care of a couple of things. Good luck!
I will try that tonight, I'll report back on my success

Something I've been thinking about. You will have to somehow separate which program is executed for each user. If user 'A' has /bin/true and user 'B' has /bin/false then when B tries to mount it should never succeed and when A tries to mount it should normally succeed if no errors have occured. Also there is a huge security problem if you realize that fork-exec inherits the parents UID. Since the daemon is running as root, any user could just choose to have an "xterm" to execute everytime they mount something. The xterm would be a root shell in that case. You can however restrict the uid/gid to that of the user using set*uid(2) and set*gid(2). Nevertheless, I don't think you can use g_spawn_sync anymore. You will have to do fork-exec manually.

Last edited by dimigon (2009-04-20 15:24:10)

Heller_Barde · 2009-04-20 14:31:14

good point. i'll give it some more thought before jumping into code then.

EDIT: how about the user started some sort of notification client itself that is handling the notification and the daemon communicates with the clients through a socket. that would handle the UID issues and in my eye seems to be like "the proper way"
what do you think?

cheers Barde

Last edited by Heller_Barde (2009-04-20 14:33:29)

dimigon · 2009-04-20 14:47:29

Heller_Barde wrote:

good point. i'll give it some more thought before jumping into code then.
EDIT: how about the user started some sort of notification client itself that is handling the notification and the daemon communicates with the clients through a socket. that would handle the UID issues and in my eye seems to be like "the proper way"
what do you think?
cheers Barde

I am trying to see if it is possible to get the UID (user id) of the client who requested a mount through a DBUS/HAL message. If that is not possible, then the daemon has no way of restricting access to each user and read user-dependent configuration files. EDIT: Can you elaborate a bit more on your concept?

Last edited by dimigon (2009-04-20 15:36:39)

dimigon · 2009-04-20 15:11:34

Heller_Barde wrote:

good point. i'll give it some more thought before jumping into code then.
EDIT: how about the user started some sort of notification client itself that is handling the notification and the daemon communicates with the clients through a socket. that would handle the UID issues and in my eye seems to be like "the proper way"
what do you think?
cheers Barde

What if we just have a global configuration file where only root can alter, which will be the behaviour for all users on the system? I am not sure if it is possible to support per-user settings without going into too much fuss.

Last edited by dimigon (2009-04-20 18:40:19)

Heller_Barde · 2009-04-20 21:48:55

somehow there needs to be a notification on every xserver running on this computer, or we could just decide not to support multiple xserver instances and just put the xserver to use in the config file (like "DISPLAY=:0.0") we probably have to put the user we want to run the notification in the config file too, since I don't know how we can for sure figure out which user started the xserver.

so i propose something like this for a default configuration:

command="/bin/true"
user="foobar"
display=":0.0"

dimigon · 2009-04-21 09:29:32

Heller_Barde wrote:

somehow there needs to be a notification on every xserver running on this computer, or we could just decide not to support multiple xserver instances and just put the xserver to use in the config file (like "DISPLAY=:0.0") we probably have to put the user we want to run the notification in the config file too, since I don't know how we can for sure figure out which user started the xserver.
so i propose something like this for a default configuration:
command="/bin/true"
user="foobar"
display=":0.0"

Why is the X server a dependency on this? skvm works without an X server as well as with an X server. In case you want the notification to be a program that needs the X server then that is optional. Nevertheless this still does not solve the aforementioned problems. I think it is not really feasible to have per user settings. Even if you put them in a single configuration file, when you get a request to mount you still don't know which program to launch because you don't know which user requested a mount.

EDIT: perhaps it is possible to get the uid using dbus_bus_get_unix_user(...) or org.freedesktop.DBus.GetConnectionUnixUser. I have not checked into that yet.

Last edited by dimigon (2009-04-21 12:30:07)

Heller_Barde · 2009-04-21 12:37:59

ah! my bad. I didn't think far enough
of course there is no need for an xserver, but it was the only szenario where a notification made sense for me. (the display=:0.0 line is just to set the environment variable $DISPLAY, which wouldn't break anything even with a non-X program

as for the user, i was thinking that there would only be one relevant user logged in... but of course there could be something like a "subscribe-to-skvm" command, which could be executed as soon as you want to be notified.

but by now this seems to be becoming more and more of a non-KISS-thing and i propose to only add a simple execution hook to the device_added function (which would default to /bin/true to not alter the default behaviour) and have all the other fuss externalized as to make it as modular as possible (i would prefer to write a python script to handle all the stuff)

what do you think

cheers Barde

PS: you mentioned something about user requesting a mount... I'm not sure what you meant, because as far as i get it, skvm just mounts a device as soon as it notices it... and my basic idea was to simply stall the mounting until the user makes a choice. but i see the problem now, because if the user said no, he would have no chance to mount the device again short of disconnecting and reconnecting it.
hmmm, there is a lot to think of

dimigon · 2009-04-21 13:03:55

Heller_Barde wrote:

PS: you mentioned something about user requesting a mount... I'm not sure what you meant, because as far as i get it, skvm just mounts a device as soon as it notices it... and my basic idea was to simply stall the mounting until the user makes a choice. but i see the problem now, because if the user said no, he would have no chance to mount the device again short of disconnecting and reconnecting it.
hmmm, there is a lot to think of

What I meant by saying "a user requesting a mount" is that skvm is notified by dbus/hal that a new device has been inserted. Now if you have a program to be running to decide whether mounting should take place or not the easiest thing to do would be to have a simple #define in skvm or a central configuration file which only root can alter with the absolute path to the program that you want to execute. This will apply to all users on the system. Since only root is liable for choosing
which program will run, the security risk of running a program with inherited root permissions is diminishing. A simple notification dialog can't do much unless it is poorly coded.

Last edited by dimigon (2009-04-21 13:05:52)

Heller_Barde · 2009-04-22 09:18:39

Ah. you meant the requesting part like "when a user actually plugs a new device in". good, good. and about the config. it seems to me that it would be sensible to just hardcode (i mean #define) something like /etc/skvm/mountrequest and then root can put his script in that place (or symlink /bin/true there)

I agree with the "if root choses the program, it's his own fault if it does any harm" policy. (i will still put a "su $myuser -c /usr/bin/foobar" in that script, just to be sure and deal with the theming issues '^^)

okay, now that is settled, I'll try and start coding

cheers Barde

robmaloy · 2009-04-22 09:37:38

would it be possible that skvm doesn't do the mounting automatically,
but instead (or additionally) having a client talking to it and giving the user some kind of list
from which he can choose to mount / unmount a certain drive?

if that's not your intention, i'll have to learn some C and fork your project

Last edited by robmaloy (2009-04-22 09:38:41)

jerryluc · 2009-04-22 15:30:38

dimigon wrote:

jerryluc wrote:
@dimigon: thanks for the clear up. I've installed the git-version, and tried what you said. My external hdd got automounted by skvm, and the i umounted it ("umount /dev/sdb1"). But the directory didnt get deleted.
Hi, make sure the directory is not being used when you eject the drive, either by being already mounted for another device or you are cd-ed into that directory at the moment of ejecting (in which case umounting would fail). Either way, you can take a look at the system logs (cat /var/log/messages.log | grep -i skvm) for a warning message caused by a failing rmdir(2) similar to the following
Apr 15 15:54:15 scron-gr ./skvm[13139]: skvm.c:288: Device or resource busy
In any way, does it do this for a particular volume or do you have this problem generally with any mounteable device?

Skvm works as expected for my usb stick, but not for my WD Passport external HDD, It doesn't remove the dir afterwards.

From /var/log/message.log:

Apr 22 16:43:10 sinus /usr/bin/skvm[12542]: skvm.c:304: Device or resource busy

Apr 22 17:24:49 sinus skvm[13106]: skvm.c:304: Permission denied

two different incidents.

Heller_Barde · 2009-04-22 20:23:29

robmaloy wrote:

would it be possible that skvm doesn't do the mounting automatically,
but instead (or additionally) having a client talking to it and giving the user some kind of list
from which he can choose to mount / unmount a certain drive?
if that's not your intention, i'll have to learn some C and fork your project

well, the first thing i am planning on implementing. the thing with unmounting... i hadn't thought of that, actually... very good idea, though
EDIT: i just realized that i sounded like the dev of that project. to be clear, i am not i am just contributing (or at least trying to)

cheers
Barde

Last edited by Heller_Barde (2009-04-22 20:24:35)

dimigon · 2009-04-23 00:23:53

jerryluc wrote:

dimigon wrote:
jerryluc wrote:
@dimigon: thanks for the clear up. I've installed the git-version, and tried what you said. My external hdd got automounted by skvm, and the i umounted it ("umount /dev/sdb1"). But the directory didnt get deleted.
Hi, make sure the directory is not being used when you eject the drive, either by being already mounted for another device or you are cd-ed into that directory at the moment of ejecting (in which case umounting would fail). Either way, you can take a look at the system logs (cat /var/log/messages.log | grep -i skvm) for a warning message caused by a failing rmdir(2) similar to the following
Apr 15 15:54:15 scron-gr ./skvm[13139]: skvm.c:288: Device or resource busy
In any way, does it do this for a particular volume or do you have this problem generally with any mounteable device?
Skvm works as expected for my usb stick, but not for my WD Passport external HDD, It doesn't remove the dir afterwards.
From /var/log/message.log:
Apr 22 16:43:10 sinus /usr/bin/skvm[12542]: skvm.c:304: Device or resource busy

Apr 22 17:24:49 sinus skvm[13106]: skvm.c:304: Permission denied
two different incidents.

I believe that for some reason the drive is not unmounted correctly. The first error message happens when you try to remove a directory that is mounted. Another thing, do you run skvm as root? (most likely yes). Before you eject the drive and after you have unmounted it, try to delete the directory manually using rmdir(1) and see if that fails. I also happen to have a WD Passport (reiserfs) and works fine.

Last edited by dimigon (2009-04-23 00:27:05)

milomouse · 2009-04-23 05:01:45

Psst.. hey, just jumping in here to say thank you. Very glad to have an alternative to FAM, as I'm trying to weedle out everything gnome-related. SKVM works great, I commend you.

tomk · 2009-04-23 06:25:32

milomouse - FYI, FAM is not gnome-related in any way. It is simply used by GNOME, as it is by KDE and other applications.

milomouse · 2009-04-23 07:08:29

That's what I was referring to but I can see where the confusion was in my previous statement. Sorry about that. I tend to be vaguely-specific.

dimigon · 2009-05-21 10:34:26

*news*

I've permanently deleted the github repository. All development happens at suckless.org, I've edited the first post and added instructions on how to clone the latest development tip.

neoxic · 2009-05-21 11:05:57

dimigon wrote:

*news*
I've permanently deleted the github repository. All development happens at suckless.org, I've edited the first post and added instructions on how to clone the latest development tip.

Why the switch from git to mercurial? Just curious.

dimigon · 2009-05-21 11:23:21

neoxic wrote:

Why the switch from git to mercurial? Just curious.

It was more of a switch from github to suckless.

sfauzia · 2009-05-30 05:53:10

Something strange with my SD card. It'll mount it automatically if it isn't in the SD card slot on boot, or if I pull it out and push it in again. Is it possible for it to mount it during the boot process? It'd be preferable, thanks!

Last edited by sfauzia (2009-05-30 06:36:35)

Arch Linux

#26 2009-04-19 20:44:06

Re: A very lightweight volume manager

#27 2009-04-19 23:57:03

Re: A very lightweight volume manager

#28 2009-04-20 11:35:03

Re: A very lightweight volume manager

#29 2009-04-20 12:05:56

Re: A very lightweight volume manager

#30 2009-04-20 12:07:09

Re: A very lightweight volume manager

#31 2009-04-20 12:26:41

Re: A very lightweight volume manager

#32 2009-04-20 14:31:14

Re: A very lightweight volume manager

#33 2009-04-20 14:47:29

Re: A very lightweight volume manager

#34 2009-04-20 15:11:34

Re: A very lightweight volume manager

#35 2009-04-20 21:48:55

Re: A very lightweight volume manager

#36 2009-04-21 09:29:32

Re: A very lightweight volume manager

#37 2009-04-21 12:37:59

Re: A very lightweight volume manager

#38 2009-04-21 13:03:55

Re: A very lightweight volume manager

#39 2009-04-22 09:18:39

Re: A very lightweight volume manager

#40 2009-04-22 09:37:38

Re: A very lightweight volume manager

#41 2009-04-22 15:30:38

Re: A very lightweight volume manager

#42 2009-04-22 20:23:29

Re: A very lightweight volume manager

#43 2009-04-23 00:23:53

Re: A very lightweight volume manager

#44 2009-04-23 05:01:45

Re: A very lightweight volume manager

#45 2009-04-23 06:25:32

Re: A very lightweight volume manager

#46 2009-04-23 07:08:29

Re: A very lightweight volume manager

#47 2009-05-21 10:34:26

Re: A very lightweight volume manager

#48 2009-05-21 11:05:57

Re: A very lightweight volume manager

#49 2009-05-21 11:23:21

Re: A very lightweight volume manager

#50 2009-05-30 05:53:10

Re: A very lightweight volume manager

Board footer