Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Copying Gentoo installation with rsync -a removed setuid
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo
View previous topic :: View next topic  
Author Message
ElektroVirus
n00b
n00b


Joined: 27 Jan 2020
Posts: 13

PostPosted: Wed Sep 16, 2020 11:17 am    Post subject: Copying Gentoo installation with rsync -a removed setuid Reply with quote

Hello,

I bought a new laptop and didn't want to install my whole Gentoo installation from scratch. So, I created only a new partition table and partitions (LUKS + LVM but it doesn't really matter). Then, I used "rsync -a" to copy the whole existing installation to the new laptop. After reconfiguring /etc/fstab and the bootloader and booting to the new system everything seemed to work.

But I found a few problems. The first one was that both i3lock and the lockscreen from KDE Plasma didn't work: my password was unable to unlock the lock screens. I had to kill i3lock or use loginctl unlock-session to unlock the KDE Plasma session from another TTY. After some searching I found a thread from these forums: the solution was to
Code:
chmod 4755 /sbin/unix_chkpwd
.

The next problem which I discovered that ping didn't work (it didn't have permissions) and I already knew the solution, "chmod 4755 /bin/ping".

Now I found out that Wireshark does not work, probably for the same permission problem. Now to the questions. Why didn't "rsync -a" copy the permission bits for these binaries? And how do I now fix the issue, how can I know which all binaries need these setuid/setgid-bits?

ElektroVirus
Back to top
View user's profile Send private message
alamahant
Advocate
Advocate


Joined: 23 Mar 2019
Posts: 3879

PostPosted: Wed Sep 16, 2020 2:37 pm    Post subject: Reply with quote

Hi,
When using rsync invoke it thus
Code:

rsync -aAXHv /src/ /dst/

This will preserve perms, links and extended attributes.
:D
Back to top
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 21724

PostPosted: Wed Sep 16, 2020 4:30 pm    Post subject: Reply with quote

--archive is documented as being -rlptgoD (omitting -HAX). -p is --perms, so setuid should have been copied. OP: are you sure that setuid/setgid were present on the old filesystem? Perhaps the relevant programs were built to use Linux capabilities, and so they were not setuid/setgid. I think losing xattrs would have the same symptoms as reported.

You could try using equery check to look for invalid permissions, but I am not sure if that can find invalid xattrs.
Back to top
View user's profile Send private message
SlashBeast
Retired Dev
Retired Dev


Joined: 23 May 2006
Posts: 2922

PostPosted: Wed Sep 16, 2020 5:55 pm    Post subject: Reply with quote

Your problem is not suid that is being lost -- those are copied just fine. What is not are file capabilities.

Code:

# getcap /sbin/unix_chkpwd
/sbin/unix_chkpwd cap_dac_override=ep


Check 'man 7 capabilities' to understand them a bit more.

Those are stored in extended attributes and require '-X' flag to rsync to preserve them. Alternatively you can go with -filecaps USE flag if you want to revert to suid binaries.
Back to top
View user's profile Send private message
figueroa
Advocate
Advocate


Joined: 14 Aug 2005
Posts: 2965
Location: Edge of marsh USA

PostPosted: Thu Sep 17, 2020 4:47 am    Post subject: Reply with quote

A couple of times I've used cp -a and successfully copied a system partition to another partition. I don't think that's the best approach because it copies everything, including a lot of files don't really want or need to copy. It's sloppy, but I'm pretty sure it worked. Ordinarily for backup purposes I tar each of the directories in the partition root, i.e. /, using --xattrs and --numeric-owner switches. For example, the beginning of my backup script reads:
Code:
#!/bin/sh
#gentoo2bak.scr
mount /mnt/backup0
cd /
tar cpf /mnt/backup0/sysbak/bin.tar.zst -I "zstd -9 -T0" --xattrs --numeric-owner bin/


For those special directories where you don't want to traverse the directory tree, such as /sys or /proc, I add the --no-recursion switch and/or selectively exclude sub-directories I don't want to copy with a list of exclusions using the -X /parth/to/file/with/list/of/exclusions/exclude.var switch.

What I end up with is a collection of compressed tar archives running now about 3.3 GB, that I can restore in whole or selectively to any destination partition. I've done this successfully many times for over 10 years (probably more).
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi
Back to top
View user's profile Send private message
ElektroVirus
n00b
n00b


Joined: 27 Jan 2020
Posts: 13

PostPosted: Fri Sep 18, 2020 9:17 am    Post subject: Reply with quote

Thank you for your quick replies!
You were correct, those were the file capabilities which were missing and not the SUID. I do have a backup from my old system (I cloned the SSD to a HDD), but I'm not so eager to copy everything again since this was a few weeks ago and I am not quite sure what I have already changed since it.

Can Portage somehow recover these missing file capabilities easily? If not, I will probably use getattr to read the attributes from the old filesystem and set the missing capabilities with setattr.

But, as rsync man page reads;
Code:
--archive, -a            archive mode; equals -rlptgoD (no -H,-A,-X)

my filesystem is now missing hardlinks, Access control lists and these extended attributes. Are these missing hard links and ACL a problem, are they in use by the system? If, then I must roll back to my backup completely.


And thanks Andy Figueroa for the tip of the backup script, writing that kind of script is definitely a good idea and I must make one for myself.

I'm so glad for how helpful this community is :)


EDIT:

I restored the missing attributes from my backup by mounting it and running
Code:
getfattr -d -m '.*' -R /mnt/gentoo/ > /root/attr_dump


After removing from the paths the part "/mnt/gentoo/" in file /root/attr_dump (this could have been omitted by chrooting into the old filesystem before getting the attribute dump) the attributes could be applied to my new system by running

Code:
setfattr --restore=/root/attr_dump


I still am not sure about the ACLs or hard links but everything seems to work now as before.
Hopefully this edit will help someone in the future :)

ElektroVirus
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum