From: Marc Joliet <marcec@gmx.de>
To: linux-btrfs@vger.kernel.org
Subject: File permissions lost during send/receive?
Date: Tue, 24 Jul 2018 14:16:15 +0200 [thread overview]
Message-ID: <8202618.Xtt70Sb46P@thetick> (raw)
[-- 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 --]
next reply other threads:[~2018-07-24 13:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-24 12:16 Marc Joliet [this message]
2018-07-24 17:53 ` File permissions lost during send/receive? Andrei Borzenkov
2018-07-24 19:46 ` Duncan
2018-07-24 20:42 ` Marc Joliet
2018-07-25 1:30 ` Duncan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8202618.Xtt70Sb46P@thetick \
--to=marcec@gmx.de \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.