All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

             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.