:: Re: [DNG] Fwd: For all you automoun…
Top Page
Delete this message
Reply to this message
Author: Didier Kryn
To: dng
Subject: Re: [DNG] Fwd: For all you automounter programmers
Le 03/05/2016 17:27, fsmithred a écrit :
> On 05/03/2016 09:34 AM, Didier Kryn wrote:
>> Le 03/05/2016 14:48, hellekin a écrit :
>>> On 05/03/2016 12:16 PM, Jim Murphy wrote:
>>>> Problem, blkid uses a cache that is only updated when root runs blkid.
>>>> Any changes are not automatically updated. A user only sees the cache.
>>>> The issues is, fsr is trying to do everything as a "user" so tools like
>>>> lsblk and blkid don't work for this case. For blkid, the cache will not
>>>> be up to date when say a flash-drive is add/or removed.
>>> You might be interested in using jaromil's version of sup to compile a
>>> static binary that will elevate privilege for "that" user running *blk*
>>> commands. Not as sexy as running without root, but a good use-case for
>>> the new hashing functionality of sup.
>>> https://git.devuan.org/jaromil/sup
>>      Until I can see this myself (this evening at home on devuan-jessie) I
>> assume the hotplug manager will invoke blkid upon insertion of the device,
>> and therefore it will take care of updating blkid's cache. This is
>> consistent with the very idea of having a cache; it would make no sense
>> otherwise. blkid is explicitely designed to be invoked by udev (it has an
>> "udev" formatting switch) and we know vdev invokes it as well.

>>      I can see possible reasons why it wouldn't be invoked:

>>      1) the system doesn't use a hotplugger (either static, or devtmpfs)
>>      2) udev has been replaced by eudev and eudev does otherwise.
>>      3) udev now makes function calls to blkid's library instead of
>> invoking the program, and the cache is only maintained by the program.

>>       Jim, did you try '/sbin/blkid -c /dev/null' ? This bypasses the
>> cache. For me, it shows only the hot-plugged devices and not the main hard
>> disk.

>>         Didier

> Here's a fourth reason (I think) - gvfs is not installed. If it were, I
> wouldn't need to create a way to mount removable drives, I'd just click
> the icon when it pops up. But that's not going to change right now - I
> want to see how far I can get without libsystemd0 and without adding
> outside repos.
> /sbin/blkid -c /dev/null does not work for unprivileged user.
> Jim suggested two possible solutions to this problem - maybe a udev rule
> could do it (I don't know) or add the user to the disk group.
> One solution I thought of is to give sudo NOPASSWD privs to the user for
> /sbin/blkid. I don't like any of those solutions.
> I have a working script that will mount removable devices by label if one
> exists, or by device if there's no label. It works for usb,sd/mmc and
> cd/dvd. This is a command-line only script (no yad or zenity needed) and
> the solution I wrote into the script is to add 'su -c blkid' which
> completely defeats the reason for using pmount. So, it's more a proof of
> concept than a useful tool. I'll post it (not here in mailing list) if
> anyone is interested in playing with it.
> Another idea I had is that maybe there is some perl module that can access
> this information for the user, without invoking root. If that's the case,
> maybe I'll dust off the perl books and see what I can do.
> -fsr

     I made experiments yesterday evening with a laptop running 

     1) '/sbin/blkid -c /dev/null' , invoked by non-root, produces no 

     2) '/sbin/blkid' , invoked as non-root, lists all connected block 
devices. I don't know why this does not work for you. Sure I have gvfs 
installed, but I doubt it has any relation with the operations of blkid.

     For me, this shows that blkid is invoked by udev when the device is 
connected and the cache is updated. In the absence of a config file for 
blkid, which is the case on Devuan-Jessie, the cache of blkid is 
/run/blkid/blkid.tab and it is a readable text file. It could be read 
directly by any application.

     BTW, I did this on tty1, with no running DE, and I noticed 
something abnormal: the startup hangs on after spawning slim until a 
first graphical session is started. As long as no graphical session has 
been started, there is no getty running on any of the virtual consoles.