File permissions lost during send/receive?

File permissions lost during send/receive?

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 2250 bytes --]

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
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: File permissions lost during send/receive?

[Andrei Borzenkov]

[-- Attachment #1.1: Type: text/plain, Size: 2429 bytes --]

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).

> 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
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: File permissions lost during send/receive?

[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

(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.

-- 
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

Re: File permissions lost during send/receive?

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 3625 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: File permissions lost during send/receive?

[Duncan]

Marc Joliet posted on Tue, 24 Jul 2018 22:42:06 +0200 as excerpted:

> 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.)

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. =:^)

-- 
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