[SOLVED] Recover from blunder: "sudo chown -R radicale:radicale /"

Cbhihe · 2022-10-01 22:29:16

I could roll back "most" (if not all) of the owner:group properties of files on an up-to-date Archlinux OS clobbered with:

# chown -R radicale:radicale /

I have three immediate issues (and probably far more down the line) as far as I can tell:

1) I am missing (for all but one of the system files) which files much have their setuid bit set.
The ownership properties of /usr/bin/sudo, /usr/bin/su and /usr/lib/polkit-1/polkit-agent-helper-1 should be "root:root" and I got them back first with:

# chmod u+s /usr/bin/sudo                                          # EDIT: changed from erroneous "# chown u+s /usr/bin/sudo" which made no sense.
# chmod u+s /usr/bin/su                                              # EDIT: also needed
# chmod u+s /usr/lib/polkit-1/polkit-agent-helper-1                           # EDIT: also needed

I figure that if somebody could post a relation of Arch linux files with the setuid bit set, I could take care of that rather easily either by hand or with a script. (Although I don't expect more than 20 to 30 files to crop up on a plain Arch OS. I guess the cmd would be:

sudo find -type f -perm -4000

2) I cannot launch nautilus, aka "Files" any longer from the Gnome desktop GUI. However, going to terminal, I can execute either nautilus or /usr/bin/nautilus (with the same result), but the system complains loudly:

Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)

(org.gnome.Nautilus:34023): dconf-WARNING **: 23:59:57.710: failed to commit changes to dconf: The connection is closed
(org.gnome.Nautilus:34023): dconf-WARNING **: 23:59:57.710: failed to commit changes to dconf: The connection is closed
(org.gnome.Nautilus:34023): IBUS-WARNING **: 23:59:57.742: Unable to connect to ibus: Unexpected lack of content trying
** (org.gnome.Nautilus:34023): CRITICAL **: 23:59:57.763: update_dbus_opened_locations: assertion 'dbus_object_path' failed
(org.gnome.Nautilus:34023): dconf-WARNING **: 23:59:57.763: failed to commit changes to dconf: The connection is closed
(org.gnome.Nautilus:34023): GLib-GIO-CRITICAL **: 23:59:57.798: g_dbus_proxy_new_sync: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
(org.gnome.Nautilus:34023): GLib-GIO-CRITICAL **: 23:59:57.798: g_dbus_proxy_get_cached_property: assertion 'G_IS_DBUS_PROXY (proxy)' failed 
(org.gnome.Nautilus:34023): dconf-WARNING **: 00:00:01.997: failed to commit changes to dconf: The connection is closed
(org.gnome.Nautilus:34023): dconf-WARNING **: 00:00:01.997: failed to commit changes to dconf: The connection is closed
** (org.gnome.Nautilus:34023): CRITICAL **: 00:00:02.003: update_dbus_opened_locations: assertion 'dbus_object_path' failed
(org.gnome.Nautilus:34023): GLib-GIO-CRITICAL **: 00:00:02.043: g_dbus_proxy_new_sync: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
(org.gnome.Nautilus:34023): GLib-GIO-CRITICAL **: 00:00:02.043: g_dbus_proxy_call_internal: assertion 'G_IS_DBUS_PROXY (proxy)' failed

3) When starting a tile with CTRL-B + " in tmux or when first launching tmux with the custom cmd:

tmux -2u new-session \; split-window -h \; split-window -v \; select-pane -t 0 \; send-keys ' ' C-m \;

I get:

gnome-keyring-daemon: no process capabilities, insecure memory might get used
** Message: 23:47:24.822: couldn't access control socket: /run/user/1000/keyring/control: Permission denied
** Message: 23:47:24.822: couldn't access control socket: /run/user/1000/keyring/control: Permission denied
discover_other_daemon: 0** Message: 23:47:24.823: couldn't connect to dbus session bus: Could not connect: Permission denied
** Message: 23:47:24.823: The gnome-keyring control directory cannot be accessed: /run/user/1000/keyring: Permission denied
** (gnome-keyring-daemon:33755): WARNING **: 23:47:24.823: couldn't create socket directory: /run/user/1000/keyring-9ZB7S1: Permission denied
** (gnome-keyring-daemon:33755): WARNING **: 23:47:24.823: couldn't bind to control socket: /run/user/1000/keyring-9ZB7S1/control: Permission denied

___________________________________________________

At this point I have the damaged system running in the same session in which the mistake happened (with no reboot in between). I would like to try to bring that system back with no reinstall.

Last edited by Cbhihe (2022-10-05 08:41:24)

TadaenSylvermane · 2022-10-01 23:29:58

There is no real fix for this other than reinstalling. There are thousands of files with varied permissions. I suppose technically it could be done. But it would take a long long time. Not worth it. You can reinstall and reconfigure faster than you could even attempt to fix that. Even if you get some things working you will run into problems stemming from this from now on.

Cbhihe · 2022-10-01 23:37:49

On point 3):

Going to the control socket:

sudo ls -l /run/user/1000/keyring/control
srw-rw-rw- 1 root root 0 Oct  1 16:00 /run/user/1000/keyring/control

I changed the /run/user/1000 directory ownership to user 1000, with:

sudo chown -R USER:USER /run/user/1000

and now when launching a new tmux tile: I get:

gnome-keyring-daemon: no process capabilities, insecure memory might get used

Only reinstalling gnome-keyring from base group gnome fixed the keyring problem.

On point 2):

After reinstalling gnome-keyring, the errors and warnings of point 2) become:

Error creating proxy: Cannot spawn a message bus when AT_SECURE is set (g-io-error-quark, 0)
Error creating proxy: Cannot spawn a message bus when AT_SECURE is set (g-io-error-quark, 0)
Error creating proxy: Cannot spawn a message bus when AT_SECURE is set (g-io-error-quark, 0)
Error creating proxy: Cannot spawn a message bus when AT_SECURE is set (g-io-error-quark, 0)
Error creating proxy: Cannot spawn a message bus when AT_SECURE is set (g-io-error-quark, 0)

(org.gnome.Nautilus:47551): dconf-WARNING **: 03:00:45.727: failed to commit changes to dconf: Cannot spawn a message bus when AT_SECURE is set
(org.gnome.Nautilus:47551): dconf-WARNING **: 03:00:45.727: failed to commit changes to dconf: Cannot spawn a message bus when AT_SECURE is set
(org.gnome.Nautilus:47551): IBUS-WARNING **: 03:00:45.764: Unable to connect to ibus: Unexpected lack of content trying to read a line
** (org.gnome.Nautilus:47551): CRITICAL **: 03:00:45.810: update_dbus_opened_locations: assertion 'dbus_object_path' failed
(org.gnome.Nautilus:47551): dconf-WARNING **: 03:00:45.810: failed to commit changes to dconf: Cannot spawn a message bus when AT_SECURE is set
(org.gnome.Nautilus:47551): GLib-GIO-CRITICAL **: 03:00:45.835: g_dbus_proxy_new_sync: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
(org.gnome.Nautilus:47551): GLib-GIO-CRITICAL **: 03:00:45.835: g_dbus_proxy_get_cached_property: assertion 'G_IS_DBUS_PROXY (proxy)' failed

Last edited by Cbhihe (2022-10-02 01:05:05)

Cbhihe · 2022-10-01 23:47:45

@TadaenSylvermane:

Allow me to disagree at least partially, as rebuilding that particular system from scratch would take weeks probably.
In any case the problem is one of file ownership and not of execution privilege. That last part was left untouched (if I'm completely clear on what happened).
In any case I'm game to try to fix things.

If you run an Arch system, can you send me a relation of your system files with the setuid bit set ? They should not be so many. If I had a second system by me, I already would be in business fixing things.

Last edited by Cbhihe (2022-10-01 23:50:11)

jonno2002 · 2022-10-02 02:33:17

i may be missing somthing here but shouldnt this work:

chown -R root:root /
chown -R username:username /home/username (repeat for each user)

Stratoblaster · 2022-10-02 02:40:59

I think in some cases, yes. However, if you look at an Arch system in /dev, you'll see some things listed as
root:tty
root:kvm
root:uucp
and so forth.

So a blanket root:root may not be the best option.

Last edited by Stratoblaster (2022-10-02 02:42:05)

jonno2002 · 2022-10-02 03:14:39

/dev /proc /run /sys /tmp are populated at boot, but yes there are other places where ownership differs from root:root so my solution isnt perfect and TadaenSylvermane is pretty much correct

seth · 2022-10-02 06:53:22

https://wiki.archlinux.org/title/Pacman … dependency?

You could extract the ownership from the mtree (e. linking paccheck and pacrepairfile from pacutils) but since some post-install hooks/scripts might alter ownership or permissions it's probably more robust to just re-install all packages.
Stuff like "/run/user/1000/keyring/control: Permission denied" will fix w/ a reboot, because /run is a tmpfs

The remaining problem would be process generated data (logs, caches, …) and I don't think that there's a generic way to fix that.
http, ftp, mail and sql daemons typically won't run as root and limit their stuff to their specific user - looking around in /var/{cache,log} is likely necessary. In doubt and if you don't care about the caches/logs, you could just delete archive them.

Cbhihe · 2022-10-02 15:53:45

@jonno2002, @Stratoblaster, @seth, thank you for chiming in. Much appreciated.

Sorry, I forgot to mention background info:

OS is a 64 bit UEFI system with GRUB as bootloader. Secure boot is disabled. SSD internal has EFI partition and ext4 file syst.
It runs GNOME 3 with GDM on X11 ... I think, because I see that it also has Wayland support in Qt 6. Installed packages include:

extra/qt6-wayland 6.4.0
extra/wayland 1.21.0
extra/xorg-wayland 22.1.3

After more than 10 hours working on the system I am at a point where errors in point 2) of OP have disappeared. The host now boots past the Grub menu and then freezes soon after just when it normally present the user with a choice of users (2 interactive login users from what I have seen) to start a session. Now dropping to console, bypassing gdm to try to make progress. See screen shot when booting in maintenance mode to console with last of boot babble on display here: https://imagebin.ca/v/6x5ldFJLosIj.

What is the best path forward ? Reinstalling gdm or even Xorg ?

My only equipment here is slow WiFi, an Arch ISO pendrive, an iPad as emergency screen and the faulty host. (Also have a pocket knife, but will wait before I use it).

Further pointers still greatly appreciated as I have never done this kind of surgery before.

Last edited by Cbhihe (2022-10-02 16:05:26)

Cbhihe · 2022-10-02 16:48:27

UPDATE with what seems salient in

# journalctl -xb
...
Kernel command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=............... rw single
Unknown kernel command line parameters "single BOOT_IMAGE=vmlinuz-linux", will be passed to user space.
....

Except for the above, I pored over 1800 lines of journalctl, and can report:

- services in the boot sequence start and exit sucessufully,

- all volumes per /etc/fstab mount correctly, with just an info level entry to the effect that:
"Store a System Token in an EFI Variable was skipped because of a failed condition check (ConditionPathExists=....)"

- system logs are correctly accessed, but I see:
"Rebuild Journal Catalog was skipped because of a failed condition check (ConditionNeedsUpdate=/var)."

- network comes up early on and the Network Time Synchronization service unit ( systemd-timesyncd.service ) exits fine.

- udev rules kick in fine to rename the LAN and the WiFi interfaces.

Everything I see in maintenance mode looks ok, save an irrelevant issue with an ACPI warning concerning a thermal netlink events interface not being properly registered.

@seth: I will deal with logs and cache later. But wrt your comment on reinstalling "everything", Is it sane to first try to reinstall all that has to do with the display manager, GDM, since apparently that is what fails when not booting in maintenance mode and thus not skipping GDM ?

Is there a better way ?

Last edited by Cbhihe (2022-10-02 16:51:54)

seth · 2022-10-02 17:17:53

Is it sane to first try to reinstall all that has to do with the display manager, GDM

That's hard to say w/o any error data.
You can upload the system journal of a failed graphical.target boot from the console
Eg.

sudo journalctl -b -1 | curl -F 'file=@-' 0x0.st

for the previous boot.

Cbhihe · 2022-10-02 19:23:36

@seth: here, http://0x0.st/oJz1.txt , is the output of

journalctl -b -1

for booting to the graphical.target (default). It looks like GDM related configuration files have permission problems. I surmise they really are owner:group related, e.g.:

...
systemd-xdg-autostart-generator[...]: Opening /var/lib/gdm/.config/autostart failed, ignoring: Permission denied
...
systemd[...]: Failed to resolve symlink /var/lib/gdm/.config/systemd/user.control, ignoring: Pemission denied
systemd[...]: Failed to resolve symlink /var/lib/gdm/.config/systemd/user, ignoring: Pemission denied
systemd[...]: Failed to open /var/lib/gdm/.config/systemd/user.control, ignoring: Pemission denied
systemd[...]: Failed to open /var/lib/gdm/.config/systemd/user, ignoring: Pemission denied
...
/usr/lib/gdm-x-session[...]: (EE)
/usr/lib/gdm-x-session[...]: Fatal server error:
/usr/lib/gdm-x-session[...]: (EE)) Cannot open log file "/var/lib/gdm/.local/share/xorg/Xorg.pid-1242.log"
...
/usr/lib/gdm-x-session[...]: Unable to run X server
...

There are other similar messages concerning two other services (tor and postfix) on that machine, but they are not directly relevant to fix its graphic.target boot sequence.

seth · 2022-10-02 19:29:11

Everything there should be "gdm:gdm"

Cbhihe · 2022-10-03 17:27:25

Update:

- Booting and logging in GUI session for USER 1000 and USER 1001 was successful.
The complete "sudo journalctl -b" output for USER 1000 is here: http://0x0.st/oJZn.txt

My remaining doubts center on "/var/lib/" and "/var/spool"

> ls -lAF /var/lib
total 204
1314945  4 drwxr-xr-x  4 root     root      4096 20180928-120328 accountsservice/
1314943  4 drwxrwxr-x  4 root     root      4096 20171010-221907 AccountsService/
1314946  4 drwxr-xr-x  2 root     root      4096 20170905-195854 arpd/
1314947  4 drwxr-xr-x  2 root     root      4096 20201025-115801 blueman/
1314948  4 drwx------  4 root     root      4096 20190907-183657 bluetooth/
1314949  4 drwxr-xr-x  2 root     root      4096 20180704-225108 boltd/
  262159  4 drwxrwsrwt  2 brltty   brltty    4096 20221002-030754 BrlAPI/
  262158  4 drwxrws---  2 brltty   brltty    4096 20221002-030754 brltty/
1314950  4 drwxr-xr-x  4 colord   colord    4096 20180509-153449 colord/
1314951  4 drwx--x--x 10 root     root      4096 20200726-125405 containerd/
1314953  4 drwxr-xr-x  2 root     root      4096 20171107-223517 dbus/
1314954  4 drwxr-x---  8 root     root      4096 20220411-104448 dhcpcd/
1314955  4 drwxr-xr-x  3 root     root      4096 20220703-200411 dkms/
1314956  4 drwx--x--- 15 root     root      4096 20221003-121521 docker/
1314957  4 drwxrwxrwt  2 root     root      4096 20150906-213414 ex/
1314958  4 drwxr-xr-x  4 root     root      4096 20221003-121544 flatpak/
1314959  4 drwxr-xr-x  7 root     root      4096 20221002-031745 fwupd/
1314960  4 drwxrwxr-T 13 gdm      gdm       4096 20190716-074632 gdm/
1314961  4 drwxr-xr-x  2 geoclue  geoclue   4096 20190131-180814 geoclue/
  131074  4 drwxr-xr-x  2 root     root      4096 20211129-123221 hp/
1314963  4 drwxr-xr-x  2 root     root      4096 20221003-181343 krb5kdc/
  262147  4 drwxr-xr-x 11 root     root      4096 20221002-030751 libvirt/
1314964  4 drwxr-x---  2 root     root      4096 20170404-072536 locate/
 131076 32 -rw-r-----  1 root     root     29565 20221003-121521 logrotate.status
1314965  4 drwx------  2 root     root      4096 20170930-182155 machines/
1314966  4 drwxr-xr-x  2 root     root      4096 20170326-235756 misc/
1314967  4 drwxr-x---  2 root     root      4096 20221003-145209 mlocate/
1314968  4 drwx------  2 root     root      4096 20171015-230506 netctl/
1314944  4 drwx------  2 root     root      4096 20171015-111618 NetworkManager/
1314969  4 drwxr-xr-x  4 root     root      4096 20221003-181347 pacman/
1314970  4 drwx------  2 root     root      4096 20180710-192841 portables/
1314971  4 drwx------  2 postfix  root      4096 20180928-210257 postfix/
  131075  4 drwxr-xr-x  2 root     root      4096 20211111-080054 power-profiles-daemon/
1449134  4 drwx------  3 root     root      4096 20180104-102029 private/
  262145  4 drwxr-x---  3 radicale radicale  4096 20221001-190525 radicale/
1449135  4 drwxr-xr-x  4 root     root      4096 20181012-123407 samba/
1449136  4 drwxr-xr-x 12 root     root      4096 20200806-224721 systemd/
1449137  4 drwxr-xr-x  6 root     root      4096 20221003-181346 texmf/
1449138  4 drwxr-xr-x  2 root     root      4096 20220925-221924 tlp/
1449139  4 drwx------  3 tor      tor       4096 20221003-183432 tor/
1449140  4 drwxr-xr-x  3 root     root      4096 20200312-173320 tpm2-tss/
1449141  4 drwx------  2 root     root      4096 20170920-072438 udisks2/
1449142  4 drwxr-xr-x  2 root     root      4096 20221003-133556 upower/
1449143  4 drwxr-xr-x  2 root     root      4096 20220714-101232 xkb/

> ls-lAF /var/spool
total 24
5111810 4 drwxr-xr-x  2 root    root    4096 20171202-100101 anacron/
5111811 4 drwxr-xr-x  2 root    root    4096 20210405-165904 cron/
5111812 4 drwx--x---  3 root    cups    4096 20221003-181953 cups/
5111813 4 drwxrwxrwt  2 mail    mail    4096 20170326-235756 mail/
5111814 4 drwxr-xr-x 16 postfix postfix 4096 20171201-232205 postfix/
5111815 4 drwxrwxrwt  2 root    root    4096 20180906-085938 samba/

- GNOME 3 desktop manager, GDM, is fixed; everything in /var/lib/gdm is "gdm:gdm".

- Tor service is fixed. Everything in /var/lib/tor/ is "tor:tor"

- BT service appears functional; everything in /var/lib/bluetooth is "root:root"
(Couple of doubts I have addressed in a different thread.)

- docker service appears functional pending later testing.

- samba service is failed. Cannot run test now.

- netctl and netctl-auto@wifi0 services are ok.

- Postfix service is not functional. I don't know what "owner:group" property every one of its components should have in /var/lib/postfix and in /var/spool/postfix.
Could not find that information.

/var/lib/postfix itself is "postfix:root" but its contents ("master.lock" and "prng_exch") are "postfix:postfix".
/var/spool/postfix itself is "postfix:postfix", but its contents are mostly "postfix:root".
Will open new thread because Postfix is ultra-specific.

- CUPS service is not functional with service unit enabled and active.
To be addressed in another thread.

Thank you for your help.

Last edited by Cbhihe (2022-10-03 19:28:21)

seth · 2022-10-03 19:50:31

CUPS service is not functional, but I can't test it fully now.

/var/run/cups ?

Cbhihe · 2022-10-04 07:03:26

/var/run/cups/ links to /run/cups/ which is "drwxr-xr-x" and "root:root".

Trying

> sudo systemctl restart cups
Job for cups.service failed because a fatal signal was delivered causing the control process to dump core.
See "systemctl status cups.service" and "journalctl -xeu cups.service" for details.

> journalctl -xeu cups.service
...
systemd[1]: Dependency failed for CUPS Scheduler
...
systemd[1]: cups.service: Job cups.service/start failed with result 'dependency'.
...

and reading wiki to retrace install steps, so far to no avail.

seth · 2022-10-04 07:11:34

Again: /var/run is a tmpfs and will not survive a reboot, but /var/run/cups should be root:cups /var/run/cups/certs cyps:sys and /var/run/cups/cups.sock root:root

Cbhihe · 2022-10-04 12:56:53

CUPS now seems functional, but I'll have to test it at work, not just printing over the network from a lost mountain lodge. ;-)
Helluvah ride ! Thank you for your input, @seth.

Thread marked [SOLVED]

Arch Linux

#1 2022-10-01 22:29:16

[SOLVED] Recover from blunder: "sudo chown -R radicale:radicale /"

#2 2022-10-01 23:29:58

Re: [SOLVED] Recover from blunder: "sudo chown -R radicale:radicale /"

#3 2022-10-01 23:37:49

Re: [SOLVED] Recover from blunder: "sudo chown -R radicale:radicale /"

#4 2022-10-01 23:47:45

Re: [SOLVED] Recover from blunder: "sudo chown -R radicale:radicale /"

#5 2022-10-02 02:33:17

Re: [SOLVED] Recover from blunder: "sudo chown -R radicale:radicale /"

#6 2022-10-02 02:40:59

Re: [SOLVED] Recover from blunder: "sudo chown -R radicale:radicale /"

#7 2022-10-02 03:14:39

Re: [SOLVED] Recover from blunder: "sudo chown -R radicale:radicale /"

#8 2022-10-02 06:53:22

Re: [SOLVED] Recover from blunder: "sudo chown -R radicale:radicale /"

#9 2022-10-02 15:53:45

Re: [SOLVED] Recover from blunder: "sudo chown -R radicale:radicale /"

#10 2022-10-02 16:48:27

Re: [SOLVED] Recover from blunder: "sudo chown -R radicale:radicale /"

#11 2022-10-02 17:17:53

Re: [SOLVED] Recover from blunder: "sudo chown -R radicale:radicale /"

#12 2022-10-02 19:23:36

Re: [SOLVED] Recover from blunder: "sudo chown -R radicale:radicale /"

#13 2022-10-02 19:29:11

Re: [SOLVED] Recover from blunder: "sudo chown -R radicale:radicale /"

#14 2022-10-03 17:27:25

Re: [SOLVED] Recover from blunder: "sudo chown -R radicale:radicale /"

#15 2022-10-03 19:50:31

Re: [SOLVED] Recover from blunder: "sudo chown -R radicale:radicale /"

#16 2022-10-04 07:03:26

Re: [SOLVED] Recover from blunder: "sudo chown -R radicale:radicale /"

#17 2022-10-04 07:11:34

Re: [SOLVED] Recover from blunder: "sudo chown -R radicale:radicale /"

#18 2022-10-04 12:56:53

Re: [SOLVED] Recover from blunder: "sudo chown -R radicale:radicale /"

Board footer