Am Dienstag, 24. Juli 2018, 21:46:14 CEST schrieb Duncan: > Andrei Borzenkov posted on Tue, 24 Jul 2018 20:53:15 +0300 as excerpted: > > 24.07.2018 15:16, Marc Joliet пишет: > >> Hi list, > >> > >> (Preemptive note: this was with btrfs-progs 4.15.1, I have since > >> upgraded to 4.17. My kernel version is 4.14.52-gentoo.) > >> > >> I recently had to restore the root FS of my desktop from backup (extent > >> tree corruption; not sure how, possibly a loose SATA cable?). > >> Everything was fine, > >> even if restoring was slower than expected. However, I encountered two > >> files with permission problems, namely: > >> > >> - /bin/ping, which caused running ping as a normal user to fail due to > >> missing permissions, and > >> > >> - /sbin/unix_chkpwd (part of PAM), which prevented me from unlocking > >> the KDE Plasma lock screen; I needed to log into a TTY and run > >> "loginctl unlock- session". > >> > >> Both were easily fixed by reinstalling the affected packages (iputils > >> and pam), but I wonder why this happened after restoring from backup. > >> > >> I originally thought it was related to the SUID bit not being set, > >> because of the explanation in the ping(8) man page (section > >> "SECURITY"), but cannot find evidence of that -- that is, after > >> reinstallation, "ls -lh" does not show the sticky bit being set, or any > >> other special permission bits, for that matter: > >> > >> % ls -lh /bin/ping /sbin/unix_chkpwd > >> -rwx--x--x 1 root root 60K 22. Jul 14:47 /bin/ping* > >> -rwx--x--x 1 root root 31K 23. Jul 00:21 /sbin/unix_chkpwd* > >> > >> (Note: no ACLs are set, either.) > > > > What "getcap /bin/ping" says? You may need to install package providing > > getcap (libcap-progs here on openSUSE). > > sys-libs/libcap on gentoo. Here's what I get: > > $ getcap /bin/ping > /bin/ping = cap_net_raw+ep
On my system I get: % sudo getcap /bin/ping /sbin/unix_chkpwd /bin/ping = cap_net_raw+ep /sbin/unix_chkpwd = cap_dac_override+ep > (getcap on unix_chkpwd returns nothing, but while I use kde/plasma I > don't normally use the lockscreen at all, so for all I know that's broken > here too.) > > As hinted, it's almost certainly a problem with filecaps. While I'll > freely admit to not fully understanding how file-caps work, and my use- > case doesn't use send/receive, I do recall filecaps are what ping uses > these days instead of SUID/SGID (on gentoo it'd be iputils' filecaps and > possibly caps USE flags controlling this for ping), and also that btrfs > send/receive did have a recent bugfix related to the extended-attributes > normally used to record filecaps, so the symptoms match the bug and > that's probably what you were seeing. Ah, thanks, that looks like it was it! I didn't think about extended attributes, but including "xattr" in my search yielded the following patches from April this year (this turns out to be that vaguely remembered patch/ discussion that I mentioned): [PATCH] btrfs: add chattr support for send/receive [PATCH] btrfs: add verify chattr support for send/receive test However, IIUC those changes are going to be merged along with other changes into a v2 of the send protocoll, so until that gets finalized this is something to be aware of for those like me that use send/receive for backups. Anyway, thanks for pointing me in the right direction! At least now I understand what happened. Greetings -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup
signature.asc
Description: This is a digitally signed message part.
