0

The question I set /usr/bin, /usr/lib, and /usr/share to be owned by my regular user and now I am getting interesting errors is current closed as a duplicate of What if I accidentally run command “chmod -R” on system directories (/, /etc, …).

I believe the two questions are different and they shouldn't be a duplicate of one another. Although they are similar, the first one is somewhat easier to recover because the contents of those three directories are mostly (and most probably always) owned by root. And recovering from such an issue is just a matter of logging into recovery mode and fixing the ownership problem as Kaz Wolfe's answer explains.
While in the second question, the system is almost completely damaged, and it's much tougher to recover from, as shown from the answer to those questions.

1
  • 1
    Just a matter of that ... With the final step being "reboot and pray". Yeah, right.
    – muru
    Oct 17, 2018 at 6:49

1 Answer 1

Reset to default
4

I'm not sure. I'm not doing anything at the moment, just thinking out aloud.

  • I've answered a few questions on "chmod/chown-gone-wild" questions and I usually lean towards reinstallation. It's faster and safer.
  • But I'm normally talking about system-wide changes.
  • It's /var/ that is most complex.
  • Most other directories are a much more simple root: pattern until you get to /home

  • But even in /usr/, there are outliers:

    $ sudo find /usr/  -not \( -user 0 -group 0 \) -not -path "/usr/*/node_modules/*" -not -path "/usr/local/lib/python*" -printf "%p,%u:%g\n" | grep -viE "(squeeze|rabbitmq|nginx|lxc|postfix)" | sort -u | column -t -c 80 -s ,
/usr/bin/AfterShot3X64                                   oli:oli
/usr/bin/bsd-write                                       root:tty
/usr/bin/chage                                           root:shadow
/usr/bin/crontab                                         root:crontab
/usr/bin/dotlockfile                                     root:mail
/usr/bin/expiry                                          root:shadow
/usr/bin/mlocate                                         root:mlocate
/usr/bin/smerge                                          501:staff
/usr/bin/ssh-agent                                       root:ssh
/usr/bin/wall                                            root:tty
/usr/lib/dbus-1.0/dbus-daemon-launch-helper              root:messagebus
/usr/lib/evolution/camel-lock-helper-1.2                 root:mail
/usr/lib/libvte9/gnome-pty-helper                        root:utmp
/usr/lib/x86_64-linux-gnu/utempter/utempter              root:utmp
/usr/local/share/emacs                                   root:staff
/usr/local/share/emacs/site-lisp                         root:staff
/usr/local/share/fonts                                   root:staff
/usr/local/share/sgml/declaration                        root:staff
/usr/local/share/sgml/dtd                                root:staff
/usr/local/share/sgml/entities                           root:staff
/usr/local/share/sgml/misc                               root:staff
/usr/local/share/sgml                                    root:staff
/usr/local/share/sgml/stylesheet                         root:staff
/usr/local/share/texmf                                   root:staff
/usr/local/share/xml/declaration                         root:staff
/usr/local/share/xml/entities                            root:staff
/usr/local/share/xml/misc                                root:staff
/usr/local/share/xml                                     root:staff
/usr/local/share/xml/schema                              root:staff
/usr/sbin/postdrop                                       root:postdrop
/usr/sbin/postqueue                                      root:postdrop
/usr/sbin/pppd                                           root:dip
/usr/share/applications/AfterShot3X64.desktop            oli:oli
/usr/share/applications/sublime_merge.desktop            501:staff
/usr/share/icons/hicolor/128x128/apps/sublime-merge.png  501:staff
/usr/share/icons/hicolor/16x16/apps/sublime-merge.png    501:staff
/usr/share/icons/hicolor/256x256/apps/sublime-merge.png  501:staff
/usr/share/icons/hicolor/32x32/apps/sublime-merge.png    501:staff
/usr/share/icons/hicolor/48x48/apps/sublime-merge.png    501:staff
/usr/share/mime/packages/AfterShot3X64.xml               oli:oli
/usr/share/pixmaps/AfterShot3X64.png                     oli:oli
/usr/share/ppd/custom                                    root:lpadmin

  • Some of this is common some is crank from my computer. Note I excluded node_modules (which was appalling) and similarly python (abused by sudo pip3 over the years). These were thousands of files owned by $USER.

So what next?

I'm not sure. Is that answer good enough that our collective advice to people changes from You Done Messed Up A-Aron! to You can fix it?

I can't speak for this user's system before the incident, but whenever people deliberately start tearing down walls in the permissions, I worry about the other things they've done to get where they are.

I'd personally probably still recommend backup and reinstall.

3
  • 1
    Dunno about that answer, but there is one I'd suggest is good enough: terdon's here. It's for /etc, but is sufficiently flexible and should get the base system working enough for everything else to be fixed by package reinstallation/upgrade.
    – muru
    Oct 17, 2018 at 12:46
  • But if we consider your output as an example, most of the files are owned by root, it's only the group that isn't root (I'm not sure about the 501 user id, I don't have that in my case. Maybe it was because of a removed package?). So if you run chown someuser and not chown someuser: (which is the case in the question I linked) the possibility to revert back is still there. I'm not saying a solution is always possible, but most of the time it is. And users can feel less panicky as their system isn't really bricked.
    – Dan
    Oct 17, 2018 at 19:12
  • If that's what they've done, then it may be possible to reverse. The situation I'm trying to avoid here is somebody doing more than what they're admitting to (or people reading the Q&A later on). It isn't difficult to (eg) get the system to stop complaining about permissions (eg fixing the sudoers file) but leave the rest of it wide open to abuse. Perhaps where specific fixes are possible we put a DANGER ⚡ HIGH VOLTAGE warning that spells out exactly the scenario that answer applies to.
    – Oli Mod
    Oct 18, 2018 at 8:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .