Skip to main content ↑ ↓
Topic: lsblk requires sudo to populate certain fields (Read 937 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

lsblk requires sudo to populate certain fields

Hello Artix forum.

I am having an issue with lsblk.

Running the command without sudo:

Code: [Select]
$ lsblk -rpo "uuid,name,type,size,label,mountpoint,fstype"
UUID NAME TYPE SIZE LABEL MOUNTPOINT FSTYPE
 /dev/sda disk 1.8T
 /dev/sda1 part 1G  /boot
 /dev/sda2 part 1.8T
 /dev/mapper/vault crypt 1.8T  /
 /dev/sdb disk 465.8G
 /dev/sdb1 part 37.3G
 /dev/sdb2 part 1K
 /dev/sdb3 part 300G
 /dev/sdb5 part 18.6G
 /dev/sdc disk 931.5G
 /dev/sdc1 part 931.5G

Running the command with sudo:

Code: [Select]
$ sudo lsblk -rpo "uuid,name,type,size,label,mountpoint,fstype"
UUID NAME TYPE SIZE LABEL MOUNTPOINT FSTYPE
 /dev/sda disk 1.8T
76FB-96A6 /dev/sda1 part 1G  /boot vfat
d36bcd03-473c-4494-9e44-f4a46db088c1 /dev/sda2 part 1.8T   crypto_LUKS
7265f515-9893-4671-9602-74d34e141968 /dev/mapper/vault crypt 1.8T  / ext4
 /dev/sdb disk 465.8G
2cbc05bc-8eb4-4711-90e1-ef671b10257d /dev/sdb1 part 37.3G   ext4
 /dev/sdb2 part 1K
2dadd550-ddfd-434d-95af-6b1ecb47334c /dev/sdb3 part 300G   ext4
aa1bbbd7-d2f8-4e49-b0e1-c5a01e6534d6 /dev/sdb5 part 18.6G   ext4
 /dev/sdc disk 931.5G
20acf8e0-b911-41fa-8458-90ff523ec3d8 /dev/sdc1 part 931.5G   crypto_LUKS

As you can see, some of the requested fields (FSTYPE, LABEL, and UUID) only populate when I run the command with sudo.

I cannot replicate this on Arch Linux. Running lsblk will populate all requested fields, regardless of whether the command was run with sudo.

I use lsblk in some of my scripts, so this is bugging me quite a bit.

Does anybody know why these fields need sudo to populate? Is there a way I can have all requested fields populate without having to run as sudo?

Re: lsblk requires sudo to populate certain fields

Reply #1 –
I'm not sure, but probably this is the reason
lsblk man page

Re: lsblk requires sudo to populate certain fields

Reply #2 –
Quoting from this old discussion here:
https://unix.stackexchange.com/questions/210889/why-and-when-does-lsblk-require-sudo

"lsblk has always worked for regular users on arch (all columns available) so it's not a version problem. The properties are read via udev db or, if that's not available, via libblkid if you're root (see lsblk.c lines 497-607). Most likely debian/ubuntu & co have different policies/permissions/whatever on their udev... I don't know, I don't use those distros... Are you able to get those properties (UUID, FSTYPE etc) as a regular user via udevadm on ubuntu/debian e.g udevadm info -x /dev/sdb1 ? –
don_crissti
Jun 20, 2015 at 10:32"

So, if that is accurate,  and although it looks like here udevadm works without root permissions, lsblk can't get the info from udev and falls back to libblkid. In Arch udev is part of systemd while here it's separate, it could be a udev compatibility issue.

Re: lsblk requires sudo to populate certain fields

Reply #3 –
I don't get these info either as regular user. I need to be root.

"lsblk --fs" and "blkid" does not provide "UUID", "LABEL" and "FSTYPE"

but according to stackexchange discussion It is normal behavior !!!!?
 

Re: lsblk requires sudo to populate certain fields

Reply #4 –
Try this without root, change sda1 to a suitable partition if required:
Code: [Select]
udevadm info -x /dev/sda1
The output of that command  appears in less or possibly whatever is set as the pager in your shell env.
udev has the missing info without root permissions being required, but it isn't getting passed on to lsblk for whatever reason.

Re: lsblk requires sudo to populate certain fields

Reply #5 –
Quote from: ####### – on
udev has the missing info without root permissions being required, but it isn't getting passed on to lsblk for whatever reason.
you are correct.
"udevadm" has the missing information, but not passed to "lsblk"

Re: lsblk requires sudo to populate certain fields

Reply #6 –
By using the strace(1) utility, I can see that there are (at least) three ways in which LABEL and UUID  information might be available to tools such as lsblk and udevadm.

(1) beneath paths that are variations of:
/sys/devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:0a.0/0000:0d:00.0/ata9/host8/target8:0:0/8:0:0:0/block/sda/...

(2) by directly reading the block device, such as for example /dev/sda

(3) from text files whose names are variations of: /run/udev/data/b8:65

The lsblk command only tries (1) and (2).  On my up-to-date Artix system, paths (1) don't have the label and uuid fields, but do have all the stuff that lsblk can display even to a non-root user.

The lsblk code, as noted in the man page, has a fallback for some fields such as UUID and LABEL, when lsblk can't find those values below the /sys/devices hierarchy.  In that case, lsblk will also try reading the block device directly.  On my freshly installed Artix system, the permissions on the (2) block devices don't allow non-root access.  They are, for example:

brw-rw---- 1 root disk 8, 0 Jul 12 04:49 /dev/sda

That's why lsblk can only show UUID and LABEL for root users -- it gets these values (at least on systems configured such as mine) from these /dev/sd* files, which are installed to be readable only root.  For security reasons, that is a critical setting -- non-root users must NOT be allowed to read or write raw disk block devices.

The udevadm command however has another trick up its sleeve, the above (3) /run/udev files.

The (3) /run/udev/data files are essentially what udevadm copies out, for root and non-root user alike.  Try running a 'cat' (or 'more' or 'less' or ...) command on one of these files yourself.  The output will look just like what 'udevadm info' displays.

My guess would be that "lsblk" has a history dating back before the Linux "udev" system was available, and that "udevadm", as the administrative interface to "udev", thus knows about these udev specific files at /run/udev/data that lsblk never learned about.

Re: lsblk requires sudo to populate certain fields

Reply #7 –
Use the major,minor numbers gotten from stat'ing the block device file to determine which /run/udev/data file to examine.

For example, on my system, the block device /dev/sda1 has major,minor of 8,1.  So here's what happens when I run the following four commands as root:
Code: [Select]
# ls -l /dev/sda1
brw-rw---- 1 root disk 8, 1 Jul 12 04:51 /dev/sda1

# lsblk --ascii --output NAME,PATH,MAJ:MIN,FSTYPE,LABEL,PARTLABEL,UUID /dev/sda1 
NAME PATH      MAJ:MIN FSTYPE     LABEL   PARTLABEL UUID
sda1 /dev/sda1   8:1   zfs_member hotswap hotswap   6791939823015760785

# grep -E 'E:ID_FS_(LABEL|UUID)=' /run/udev/data/b8:1
E:ID_FS_LABEL=hotswap
E:ID_FS_UUID=6791939823015760785

# udevadm info /dev/sda1 | grep -E 'E: ID_FS_(LABEL|UUID)='
E: ID_FS_LABEL=hotswap
E: ID_FS_UUID=6791939823015760785

The labels, uuids, major, and minors all match up.

Re: lsblk requires sudo to populate certain fields

Reply #8 –
This is definitely a regression as I was using Artix, not Arch, for the past 3 years and only now has this bug appeared. We should trace this back to a specific package update.

Edit: Downgrading util-linux and util-linux-libs to 2.38.1 fixes the issue entirely, so this really needs to be fixed!

Edit 2: Rebuilding 2.39.1 with GNU autotools (using 2.38.1 PKGBUILD as a base) instead of meson also fixes it, so it's a compiler option bug.