ubuntu-users at list-post.mks-mail.de
Fri Jul 9 09:42:49 UTC 2010
09.07.2010 10:59, R Kimber:
> On Fri, 9 Jul 2010 07:39:41 +0200
> Nils Kassube wrote:
>> I suppose you used "blkid" and not "sudo blkid". Calling blkid without
>> sudo doesn't necessarily tell you the current state but the one from the
>> cache file /etc/blkid.tab which was written when blkid was last used
>> with sudo.
That's interesting, indeed.
I've never fallen into this trap since I wasn't aware that blkid uses a
cache file. Therefore, for me, running blkid was associated with "must
access raw device" and in turn "needs root privileges".
> Ah! Thank you. Now they match. Gparted was right it seems. Maybe there's
> a case for making blkid not useable without sudo (etc). I found the blkid
> command on a webpage that made no mention of root privileges.
I guess, there's a reason for making blkid usable as unprivileged user.
Or, to put it the other way round, something might break if it wasn't.
I'm not exactly sure if this really is the case, though.
Nevertheless, this possible pitfall might be documented more prominently.
Information is there:
the blkid(8) man page
mentions the cache file and says
| The blkid program is the command-line interface to working
| with libblkid(3) library
and if you look at the libblkid(3) man page
| Block device information is normally kept in a cache file
| /etc/blkid.tab and is verified to still be valid before being
| returned to the user (if the user has read permission on the raw
| block device, otherwise not).
So, if you read carefully and think about it, this essentially says "if
device information has changed since the last run of blkid as privileged
user and you run blkid as user without access to the raw device, the
information returned will be wrong".
But that's not what I'd call extremely and absolutely obvious.
Maybe blkid, when run under an unprivileged account, should display a
warning and tell the user that the information returned wasn't verified.
More information about the ubuntu-users