[gelöst] selbstgebautes lsblk hat andere Rechte als mitgeliefertes lsblk

[phollux]

Hallo,

ich hoffe, dass ich für meine Frage das richtige Unterforum gewählt habe.

Folgendes: Derzeit bin ich auf einem Debian bullseye unterwegs (das unten beschriebene Phänomen tritt jedoch auch unter Buster auf).
Ich habe auf dem System das vorinstallierte util-linux-Paket, welches ja unter anderem das Tool "lsblk" mitliefert.

Das hat bei mir folgende Rechte:

Code: Alles auswählen

[pk@Tux:~]$ ls -lisah /usr/bin/lsblk
91883340 124K -rwxr-xr-x 1 root root 123K Jul 28 17:14 /usr/bin/lsblk

Nun baue ich gerade ein anderes Programm, welches als AppImage von einem USB-Stick aus gestartet wird und u.a. "lsblk" aufruft.
Da ich aus Gründen das Vorhandensein von lsblk im Zielsystem nicht voraussetze, hatte ich die Idee util-linux von github runterzuladen, selbst zu bauen und direkt in das AppImage zu integrieren.

Das habe ich dann wie folgt gemacht:

Code: Alles auswählen

mkdir -p ~/appimage/usr
mkdir -p build
cd build
git clone https://github.com/karelzak/util-linux.git
cd util-linux
./configure --prefix=~/appimage/usr --without-systemd\
--enable-static-programs=blkid --disable-makeinstall-chown\
--disable-bash-completion
make -j$(nproc)
make install

Rufe ich jetzt lsblk aus "~/appimage/usr/bin/lsblk" auf, so gibt es auch eine Ausgabe. Leider aber werden FSTYPE und LABEL (unter anderem) nur dann ausgeben, wenn ich das Programm mit root-Rechten ausführe.
Beim Aufruf von "/usr/bin/lsblk" jedoch wird mir die volle Ausgabe auch als normaler Nutzer ausgegeben:

Code: Alles auswählen

[pk@Tux:~]$ /usr/bin/lsblk -o NAME,FSTYPE,LABEL
NAME        FSTYPE LABEL
nvme0n1            
├─nvme0n1p1 ntfs   Wiederherstellung
├─nvme0n1p2 vfat   
├─nvme0n1p3        
├─nvme0n1p4 ntfs   
├─nvme0n1p5 vfat   
└─nvme0n1p6 ext4   
[pk@Tux:~]$ ~/appimage/usr/bin/lsblk -o NAME,FSTYPE,LABEL
NAME        FSTYPE LABEL
nvme0n1            
├─nvme0n1p1        
├─nvme0n1p2        
├─nvme0n1p3        
├─nvme0n1p4        
├─nvme0n1p5        
└─nvme0n1p6        
[pk@Tux:~]$ su
Passwort: 
[root@Tux:/home/pk]# /home/pk/appimage/usr/bin/lsblk -o NAME,FSTYPE,LABEL
NAME        FSTYPE LABEL
nvme0n1            
├─nvme0n1p1 ntfs   Wiederherstellung
├─nvme0n1p2 vfat   
├─nvme0n1p3        
├─nvme0n1p4 ntfs   
├─nvme0n1p5 vfat   
└─nvme0n1p6 ext4   

Woran liegt das? Was mache hierbei falsch?

Viele Grüße
Phollux

[pferdefreund]

Soweit ich weiß, haben eigene Programme den user/gruppe root staff und das Originale aus Debian root root.
Eventuell wird ja die Gruppe da irgendwo geprüft.

[MSfree]

Soweit ich weiß, haben eigene Programme den user/gruppe root staff und das Originale aus Debian root root.
Eventuell wird ja die Gruppe da irgendwo geprüft.

Das hat nichts mit der Gruppe zu tun.

Vor ein paar Jahren gab es hier mal einen Thread, bei dem es darum ging, warum ping ab einer bestimmten Debian-Version nicht mehr das SUID-Bit gesetzt hatte. Die Lösung war, daß man statt dessen Capabilities verwendet. Damit kann man gezielt einstellen, welche root-Operationen für ein Programm zugelassen werden sollen. Im Falle von ping ist das das Erzeugen von bestimmten Netzwerkpaketen.

Ich denke, daß hier der gleiche Mechanismus greift. Die installierte Version hat die Capabilieties für das Executable lslbk bei der Installation erhalten. Der Selbstbau ist einfach nur ein normales Executable ohne spezielle Capabilities, darf also bestimmte Informationen aus dem /dev-Verzeichnis nicht lesen.

[phollux]

Hallo ihr beiden,

erstmal danke für die Antworten.

... [Zitat gekürzt.]

Ich denke, daß hier der gleiche Mechanismus greift. Die installierte Version hat die Capabilieties für das Executable lslbk bei der Installation erhalten. Der Selbstbau ist einfach nur ein normales Executable ohne spezielle Capabilities, darf also bestimmte Informationen aus dem /dev-Verzeichnis nicht lesen.

Das klingt sehr logisch, allerdings scheint das nicht der Fall zu sein.
Hier mal die Ausgaben mittels getcap:

Code: Alles auswählen

[root@Tux:/]# getcap -v /home/pk/appimage/usr/bin/lsblk 
/home/pk/appimage/usr/bin/lsblk
[root@Nemesis:/]# getcap -v /usr/bin/lsblk 
/usr/bin/lsblk

Wären Capabilities bei der Installation gesetzt worden, so müsste ich doch bei letzterem Aufruf von getcap auf das installierte lsblk-Programm die Capabilies sehen können, oder nicht?

Jedenfalls zeigt mir getcap das bei anderen Programmen an:

Code: Alles auswählen

[root@Tux:/]# getcap /usr/bin/ping 
/usr/bin/ping = cap_net_raw+ep

[novalix]

Vergleiche mal mit ldd, ob es unterschiedliche Verlinkungen der Binaries gibt. Möglicherweise müssen die Konfigurationsoptionen verändert werden.
util-linux ist ein etwas unübersichtliches Quellpaket, da darin etliche binaries und libs enthalten sind, die sich z.T. gegenseitig in die gewohnte Funktion helfen.

So sieht bei mir af einem buster die Verlinkung aus:

Code: Alles auswählen

root@dabase:~# ldd /bin/lsblk
        linux-vdso.so.1 (0x00007ffcdbdf9000)
        libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007f6150cf4000)
        libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 (0x00007f6150c95000)
        libsmartcols.so.1 => /lib/x86_64-linux-gnu/libsmartcols.so.1 (0x00007f6150c5d000)
        libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f6150c37000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6150a76000)
        libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f6150a6d000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6150d6b000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f6150843000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6150839000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6150818000)
        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f61507a4000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f615079f000)

NB: Ich habe in der Abfrage den kanonischen install path /bin benutzt. Das eigentliche binary liegt unter /usr/bin. Sollte keine Rolle für Dein Problem spielen.

[phollux]

Vergleiche mal mit ldd, ob es unterschiedliche Verlinkungen der Binaries gibt. Möglicherweise müssen die Konfigurationsoptionen verändert werden.

Ah, genau das war's. Danke dir!

Wenn ich mir meine Verlinkungen des installierten Binaries anschaue, unterscheiden diese sich definitiv von denen meines selbstgebauten: Und das genau bei libudev.
Durch die Installation des Pakets libudev-dev, wurde das Problem gelöst.