| View previous topic :: View next topic |
| Author |
Message |
reimugenso
n00b
Joined: 19 Jun 2018
Posts: 11
|
 Posted: Thu May 02, 2024 3:44 am Post subject: accidentally unset suid on every file |
 |
|
I'm down to fix this by re-emerging everything, but maybe there's a smarter way.
How I ended up here:
1. I backed up my previous install's home folder.
2. Unpacked the home folder to my new install.
3. Recursively changed the owner of the unpacked files (root) to the new owner (user).
4. There was a directory hardlink to root(!) in the unpacked home folder. This changed every single file in the system to user.
5. Deleted the hardlink.
6. Tried to "undo" it by using | Code: | | chown --from=user:user root:root |
7. Later discover that this somehow also unset every suid bit, and God knows what else it broke.
The system works, for now. For now I've reinstalled util-linux, shadow, and doas, but I'd like to avoid reinstalling things that don't need to be reinstalled. |
|
| Back to top |
|
 |
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2727
|
| Posted: Thu May 02, 2024 9:58 am Post subject: |
|
|
You may have lost more that setuid given I assume this touched /var too, like special groups on some directories that won't be restored even if you `emerge -e @world` everything given it doesn't touch permissions of pre-existing dirs (assumes that changes are intended) and also won't touch untracked files created at runtime by unprivileged daemons and such under these same dirs. For example:
| Code: | $ ls /var/{lib,spool,cache}/ -l | grep -v "root.*root"
/var/cache/:
total 0
drwxrwxr-x 3 root portage 0 Apr 28 05:38 distfiles
drwxr-xr-x 3 root portage 0 Apr 28 05:53 edb
drwxr-xr-x 2 man man 0 Mar 18 11:27 man
/var/lib/:
total 0
drwxr-xr-x 4 colord colord 0 Mar 25 12:06 colord
drwxr-xr-x 5 gdm gdm 0 Mar 25 12:06 gdm
drwxr-xr-x 2 geoclue geoclue 0 Mar 24 21:32 geoclue
drwxr-xr-x 2 polkitd polkitd 0 Mar 24 16:44 polkit-1
drwxr-sr-x 3 root portage 0 Apr 28 05:53 portage
drwxr-x--- 3 sddm sddm 0 Mar 25 12:33 sddm
/var/spool/:
total 0
drwx--x--- 3 root lp 0 Mar 24 20:17 cups |
Not limited to these directories, there may also be more in /var/spool like a cron or mail dir that needs special permissions, e.g. on another system that uses cronie: | Code: | $ ls -ld /var/spool/cron{,/*} /usr/bin/crontab
-rwxr-s--x 1 root crontab 47672 Apr 9 01:58 /usr/bin/crontab
drwxr-x--- 4 root cron 4096 Sep 6 2023 /var/spool/cron
drwx-wx--T 2 root crontab 4096 Aug 27 2023 /var/spool/cron/crontabs
drwxr-x--- 2 root root 4096 Apr 26 2023 /var/spool/cron/lastrun |
From a quick find on one system for non-root dirs I get (which not going to all list):
| Code: | $ find /var -type d \( -not -user 0 -and -not -gid 0 \) | wc -l
140 |
There is one in /etc too (maybe more for you): | Code: | $ ls -ld /etc/polkit-1/rules.d/
drwx------ 2 polkitd polkitd 0 Mar 24 17:29 /etc/polkit-1/rules.d/ |
That will of course vary depending on what you have installed so there can be no end to this. Only real thing to do if want to be sure everything is as it should be without a thorough investigation is to either restore a backup or re-install from scratch rather than just re-emerge packages. If have an older backup that you don't want to use due to being old, it could be used as reference for permissions at least.
Not to say it can't be usable if kept as-is, imagine will slowly discover issues, some may be less obvious than others. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21750
|
| Posted: Thu May 02, 2024 2:12 pm Post subject: Re: accidentally unset suid on every file |
|
|
When you find yourself in a hole, the first step is to stop digging. | reimugenso wrote: | How I ended up here:
1. I backed up my previous install's home folder.
2. Unpacked the home folder to my new install.
3. Recursively changed the owner of the unpacked files (root) to the new owner (user). |
This should not have been necessary. Normally, tar will restore ownership on its own, as should most other backup tools. What did you do that led to the restored home having the wrong owner? | reimugenso wrote: | | 4. There was a directory hardlink to root(!) in the unpacked home folder. This changed every single file in the system to user. |
This is impossible on most filesystems. Even root cannot hard link a directory. The operation is not permitted. In initial tests here, I cannot get chown to follow a symlink to outside the source area, at least with default options. It's not clear exactly what you ran here, so perhaps you used an option that allowed it to follow symlinks. | reimugenso wrote: | | The system works, for now. For now I've reinstalled util-linux, shadow, and doas, but I'd like to avoid reinstalling things that don't need to be reinstalled. |
I concur with Ionen. Use your most recent backup as a reference for proper ownership and permissions. You could also check the permissions in binpkgs, either your own or those downloaded from a Gentoo binhost, to supplement anything you cannot identify from personal backups. |
|
| Back to top |
|
|
reimugenso
n00b
Joined: 19 Jun 2018
Posts: 11
|
| Posted: Fri May 03, 2024 4:19 am Post subject: |
|
|
| Ionen wrote: |
Not to say it can't be usable if kept as-is, imagine will slowly discover issues, some may be less obvious than others. |
Thanks for the help. I think I had the forethought or luck to use | Code: | | chown --from=root:root user:user |
, so it should have been reversed by the opposite operation. I can't see what isn't properly set with the correct system users, just the ones that are properly set, but so far it seems to match up with your expectations.
| Hu wrote: | | This is impossible on most filesystems. Even root cannot hard link a directory. The operation is not permitted. In initial tests here, I cannot get chown to follow a symlink to outside the source area, at least with default options. It's not clear exactly what you ran here, so perhaps you used an option that allowed it to follow symlinks. |
I wish I knew. The hard link to root came from a symlink in a .wine32 folder. I confirmed it was a hard link, because ls displayed it as such, and options that don't follow symlinks went down the folder anyway.
I deleted that, with much hesitation, and the hard link to root disappeared. I could recursively chown my home folder without any side effects to root.
Unpacking the home backup tar even followed a folder that symlinked to itself (don't remember why I had to do that), which created a directory hundreds of folders deep after unpacking.
I'm using btrfs, but I don't think that allows directory hard links. All I did was tar the home folder, transfer the archive to an NTFS drive, then unpack the home folder directly to the root btrfs filesystem of the new install. |
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2727
|
| Posted: Fri May 03, 2024 12:00 pm Post subject: |
|
|
| reimugenso wrote: | Thanks for the help. I think I had the forethought or luck to use | Code: | | chown --from=root:root user:user |
, so it should have been reversed by the opposite operation. |
Ah I see that's good, was under the impression using --from was an afterthought for recovery and not how it initially went as well.
In this case it may indeed be more limited.
setuid is not used *that* much on Gentoo so list of packages shouldn't be that bad anyhow, ideally -e @world sometime still but in case anything haven't re-emerged yet, to list a few (ran on a test system that has a lot of packages, and parts of gnome+plasma at same time): | Code: | $ find /{bin,sbin,usr}/ \( -perm /4000 -or -perm /2000 \) -exec qfile -v {} + | cut -d : -f1 | sort | uniq
app-crypt/mit-krb5-1.21.2
gnome-base/libgtop-2.40.0-r2
net-misc/openssh-9.6_p1-r3
sys-apps/dbus-1.15.8
sys-apps/shadow-4.14.2
sys-apps/util-linux-2.39.3-r7
sys-auth/polkit-123
sys-fs/fuse-2.9.9-r2
sys-fs/fuse-3.16.2
sys-libs/libutempter-1.2.1
x11-drivers/nvidia-drivers-550.78 |
That test system does lack some basic things though, so also add to that any smtpd(mail) packages like exim, postfix, etc.. and cron daemons like cronie. Also any packages you had USE=suid enabled for, albeit most are off-by-default so that's likely only util-linux (already done) and maybe both slots of fuse if you have them. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21750
|
| Posted: Fri May 03, 2024 12:51 pm Post subject: |
|
|
| reimugenso wrote: | | I wish I knew. The hard link to root came from a symlink in a .wine32 folder. I confirmed it was a hard link, because ls displayed it as such, and options that don't follow symlinks went down the folder anyway. |
If you still have this link on the origin system, it would be interesting to examine it further. Not only are directory hardlinks supposed to be impossible on most filesystems, hardlinking across filesystems is impossible generally, so there shouldn't be a hard link from a home filesystem to the root filesystem. On some security configurations, users are not permitted to hard link files they do not own, and your user would not have owned /, so if that rule were active, that would be yet another barrier that should have prevented this situation from being created. I could entirely believe that there was a symlink pointing to /. Wine is very aggressive about creating a virtual Windows drive Z: that points to /, and I always need to turn that off. | reimugenso wrote: | | Unpacking the home backup tar even followed a folder that symlinked to itself (don't remember why I had to do that), which created a directory hundreds of folders deep after unpacking. |
This is also interesting. I cannot reproduce it here: | Code: | mkdir test test/a test2
(cd test/a && ln -s ../a b)
(cd test && tar -c -f ../test.tar .)
(cd test2 && tar -x -f ../test.tar) |
This reproduced the original exactly, with no deep recursion, using tar-1.35. | reimugenso wrote: | | I'm using btrfs, but I don't think that allows directory hard links. All I did was tar the home folder, transfer the archive to an NTFS drive, then unpack the home folder directly to the root btrfs filesystem of the new install. |
That sounds like a very reasonable process. |
|
| Back to top |
|
|
|
|
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
|
|
Installing Gentoo
