File permissions lost during send/receive?
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.)
I do remember the qcheck program (a Gentoo-specific program that checks the integrity of installed packages) complaining about wrong file permissions, but I didn't save its output, and there's a chance it *might* have been because I ran qcheck without root permissions :-/ .
I vaguely remember some patches and/or discussion regarding permission transfer issues with send/receive on this ML, but didn't find anything after searching through my Email archive, so I might be misremembering.
Does anybody have any idea what possibly went wrong, or any similar experience to speak of?
Greetings
Signature · 4 lines
Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup
24.07.2018 15:16, Marc Joliet пишет:
Quoted 29 lines
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(quoted diff) +0
-2-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*
Quoted 2 lines
(Note: no ACLs are set, either.)
What "getcap /bin/ping" says? You may need to install package providing getcap (libcap-progs here on openSUSE).
Quoted 14 lines
I do remember the qcheck program (a Gentoo-specific program that checks the integrity of installed packages) complaining about wrong file permissions, but I didn't save its output, and there's a chance it *might* have been because I ran qcheck without root permissions :-/ .
I vaguely remember some patches and/or discussion regarding permission transfer issues with send/receive on this ML, but didn't find anything after searching through my Email archive, so I might be misremembering.
Does anybody have any idea what possibly went wrong, or any similar experience to speak of?
Greetings
Andrei Borzenkov posted on Tue, 24 Jul 2018 20:53:15 +0300 as excerpted:
Quoted 32 lines
24.07.2018 15:16, Marc Joliet пишет:
Quoted 31 lines
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(quoted diff) +0
-2-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*
Quoted 5 lines
Quoted 3 lines
(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
(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.
Signature · 3 lines
Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Am Dienstag, 24. Juli 2018, 21:46:14 CEST schrieb Duncan:
Quoted 38 lines
Andrei Borzenkov posted on Tue, 24 Jul 2018 20:53:15 +0300 as excerpted:
Quoted 28 lines
24.07.2018 15:16, Marc Joliet пишет:
Quoted 27 lines
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:
Quoted 8 lines
Quoted 5 lines
% ls -lh
/bin/ping/sbin/unix_chkpwd(quoted diff) +0
-2-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).
Quoted 4 lines
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
Quoted 4 lines
(getcap on
unix_chkpwdreturns 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.)
Quoted 8 lines
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
Signature · 4 lines
Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup
Marc Joliet posted on Tue, 24 Jul 2018 22:42:06 +0200 as excerpted:
Quoted 9 lines
On my system I get:
% sudo getcap
/bin/ping/sbin/unix_chkpwd/bin/ping= cap_net_raw+ep/sbin/unix_chkpwd= cap_dac_override+epQuoted 3 lines
(getcap on
unix_chkpwdreturns 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.)
OK, after remerging pam, I get the same for unix_chkpwd (tho here I have sbin merge so it's /bin/unix_chkpwd with sbin -> bin), so indeed, it must have been the same problem for you with it, that I've simply not run into since whatever killed the filecaps here, because I don't use the lockscreen.
But if I start using the lockscreen again and it fails, I know one not-so- intuitive thing to check, now. =:^)
Signature · 3 lines
Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman