sudo no longer works after changes of file permissions

English Install/Boot/Login
1

Hello forum,
after I made the usr directory and all subsequent files readable, writeable and executable for all, I encountered problems with the sudo command, in that I was told that usr/bin/sudo has to be owned by the user with UID 0 and that the setuid bit has to be set. Also when I am trying to start YAST from the start-menu, root’s password was no longer accepted. However, logging-in as root from the log-in screen after booting worked fine.

Then I re-installed sudo but this didn’t change much, only the error message when issueing the sudo command changed to my user name is not in the sudoers file.
The command ls -l sudo yields -rwsr-xr-x 1 root root 155112 21. Oct 17:07 sudo

If it is important: I am using openSUSE 13.2, Linux 3.16.7-29-desktop

So I would like to ask if someone could help me fix my computer again. I have a feeling that I should reset the file permissions but I haven’t got a clue what their original setting was. Any help will be appreciated!

2

You can always query RPM database (rpm -q --dump) or try to fix permissions using

rpm --setperms -a
rpm --setugids -a

Note that in the latter case you cannot select which files will be changed; so you may consider scripting around rpm query to select only files below /usr.

3

I hope this action was a mistake from you and not something you did for some reason.

Be very cautious when you are root. You can bork your system in no time (as you have experienced.

4

In addition to what aaridvar wrote:
You can fix the permissions of all system files (well, the most important ones at least) by running this as root:

chkstat --system --set

(the “–set” should not be necessary and can be omitted)

As sudo and probably su don’t work, you have to login as root, preferably in text mode.

5

I did something similar and found the answer here:

https://madalanarayana.wordpress.com/2013/06/28/chroot-and-root-user-password-recovery-in-linux/

The section “Using ‘chroot’ for password recovery” has clearly written instructions & they work!

You may have a problem if you have lost your User passwd (SuSE no longer lets you boot into the Graphical Desktop) but that can be sorted out.

Hope this helps.

6

Yes, they work.
But a forgotten root password is not the problem here.

The OP can login as root just fine, so there’s no need to use chroot to change the password to something known or run some other command to fix the problem.

You may have a problem if you have lost your User passwd (SuSE no longer lets you boot into the Graphical Desktop) but that can be sorted out.

If you can login as root, you can also change the users’ passwords.
Just specify the user name for which you want to change the password to “passwd”. E.g. something like this:

passwd wolfi
7

Unfortunately this command did not yield the desired result. I obtained the following output. It would be great if could look over it and tell me if this information gives you another idea.

Checking permissions and ownerships - using the permissions files
/etc/permissions
/etc/permissions.easy
/etc/permissions.d/postfix
/etc/permissions.d/texlive
/etc/permissions.local
setting /usr/lib/utempter/utempter to root:utmp 2755. (wrong permissions 0777)
setting /usr/bin/at to root:trusted 4755. (wrong permissions 0777)
setting /usr/bin/crontab to root:trusted 4755. (wrong permissions 0777)
setting /usr/bin/gpasswd to root:shadow 4755. (wrong permissions 0777)
setting /usr/bin/newgrp to root:root 4755. (wrong permissions 0777)
setting /usr/bin/passwd to root:shadow 4755. (wrong permissions 0777)
setting /usr/bin/chfn to root:shadow 4755. (wrong permissions 0777)
setting /usr/bin/chage to root:shadow 4755. (wrong permissions 0777)
setting /usr/bin/chsh to root:shadow 4755. (wrong permissions 0777)
setting /usr/bin/expiry to root:shadow 4755. (wrong permissions 0777)
setting /usr/bin/fusermount to root:trusted 4755. (wrong permissions 0777)
setting /usr/lib/gnome-pty-helper to root:utmp 2755. (wrong permissions 0777)
setting /usr/bin/wall to root:tty 2755. (wrong permissions 0777)
setting /usr/bin/write to root:tty 2755. (wrong permissions 0777)
setting /usr/sbin/pppoe-wrapper to root:dialout 4750. (wrong permissions 0777)
setting /usr/lib64/kde4/libexec/kcheckpass to root:shadow 4755. (wrong permissions 0777)
setting /usr/lib64/kde4/libexec/kdesud to root:nogroup 2755. (wrong permissions 0777)
setting /usr/lib64/kde4/libexec/start_kdeinit to root:root 4755. (wrong permissions 0777)
setting /usr/lib/polkit-1/polkit-agent-helper-1 to root:root 4755. (wrong permissions 0777)
setting /usr/bin/pkexec to root:root 4755. (wrong permissions 0777)
setting /usr/sbin/lockdev to root:lock 2755. (wrong permissions 0777)
setting /usr/bin/su to root:root 4755. (wrong permissions 0777)
setting /usr/bin/mount to root:root 4755. (wrong permissions 0777)
setting /usr/bin/umount to root:root 4755. (wrong permissions 0777)
setting /usr/sbin/postqueue to root:maildrop 2755. (wrong permissions 0777)
setting /usr/sbin/postdrop to root:maildrop 2755. (wrong permissions 0777)

8

I haven’t tried this out yet because your emphasis on not being in control which files will be changed gives me the impression that issuing this command might make things worse. Could you please tell if there are any risks if I do what you said without restricting the command’s range to the directory /usr?

Otherwise I would have look up how to write such a script. I only have very superficial knowledge of administrative technicalities, and very little experience. On the other hand: it’s a challenge to be met!

9

So su, kdesu (i.e. running YaST from the menu), and kauth (doing things in KDE’s “Configure Desktop” that requires root privileges), and KDE’s lockscreen should work now, no?

Can you please post the actual error message when using sudo?
Also, did you modify /etc/sudoers in any way, maybe with “visudo”?

10

No, running YAST from the menu does not work: though I enter the correct password, the input is not accepted and I am asked to enter it again. Entering the command su and the password yields: Fehler bei der Authentifizierung (authentifiation error). Entering the command sudo and the password yields: mark ist nicht in der sudoers-Datei. Der Vorfall wird gemeldet (mark is not in the sudoers-file. The incident will be reported).

I did not modify the sudoers file. But I had a look at it and to my understanding the only user entry in there is root, the user mark isn’t mentioned there. Thus I looked at the sudo configuration program how to add the user mark, yet I really don’t understand anything of it and am afraid to make things worse. Especially I don’t know what command I am expected to enter.

Do you think that adding user mark to the sudoer list could resolve the problem?

11

No.

Did you reboot meanwhile? That might be necessary.

Can you login as root in text mode? Press Ctrl+Alt+F1 to switch to a login prompt.

12

Yes, the negative results came after rebooting. Yes, login as root in text mode is possible.

13

Ok, so we can also assume the password is correct… :wink:

Just to be sure:
What are the permissions of /etc/password and /etc/shadow?

ls -l /etc/shadow /etc/passwd

Although they should have been corrected by chstat as well if they had been wrong.

So please also post the file /etc/permissions.local (this overrides the default permissions as used by chkstat) to rule out problems there.

14

The contents of /etc/permissions.locale:

/etc/permissions.local

This file is used by chkstat (and indirectly by various RPM package scripts)

to check or set the modes and ownerships of files and directories in

the installation.

In particular, this file will not be touched during an upgrade of the

installation. It is designed to be a placeholder for local

additions by the administrator of the system to reflect filemodes

of locally installed packages or to override file permissions as

shipped with the distribution.

Format:

<file> <owner>:<group> <permission>

Please see the file /etc/permissions for general usage hints of the

/etc/permissions* files.

Please remember that logfiles might be modified by the logfile

rotation facilities (e.g. logrotate) so settings entered here might

be overridden. Also devices files (/dev/*) are not static but

managed via udev so this file can’t be used to modify device

permissions either.

suexec is only secure if the document root doesn’t contain files

writeable by wwwrun. Make sure you have a safe server setup

before setting the setuid bit! See also

https://bugzilla.novell.com/show_bug.cgi?id=263789

http://httpd.apache.org/docs/trunk/suexec.html

#/usr/sbin/suexec2 root:root 4755

setuid bit on Xorg is only needed if no display manager, ie startx

is used. Beware of CVE-2010-2240.

#/usr/bin/Xorg root:root 4711

ls -l /etc/passwd yields:
-rw-r–r-- 1 root root
ls -l /etc/shadow yields:
-rw-r----- 1 root shadow

15

Ok, no overrides there.

ls -l /etc/passwd yields:
-rw-r–r-- 1 root root
ls -l /etc/shadow yields:
-rw-r----- 1 root shadow

Looks ok as well.

Some more thoughts:
What groups is your user in?

groups

Maybe you (or something else) changed the PAM config?
Please post the output of:

cat /etc/pam.d/su /etc/pam.d/sudo

Out of other ideas for the moment, but I’ll try to think of something else tomorrow…

16

I do not think it makes situation worse than it is now. You may need to repeat chkstat invocation though. Also you may need to relogin or reboot after that (assuming you did it after corrupting file permissions).

17

@wolfi323:
The user is in group: users

Outout of cat /etc/pam.d/su:
#%PAM-1.0
auth sufficient pam_rootok.so
auth include common-auth
account sufficient pam_rootok.so
account include common-account
password include common-password
session include common-session
session optional pam_xauth.so

Outout of cat /etc/pam.d/su:
#%PAM-1.0
auth include common-auth
account include common-account
password include common-password
session include common-session

session optional pam_xauth.so

18

@arvidjaar:
Meanwhile I tried rpm --setperms -a and rpm --setperms -a (with rebooting). But the situation is exactly as before. Executing the first, I got a couple of error messages along the lines that a number of files do not exist. Would you like to see the error messages? I didn’t include them here because they are quiet numerous.

I also wanted to use rpm -q --dump but I don’t understand the usage in that I was told that a parameter was missing. I assume that I have to input the file or directory on which to apply the command. So since I want to apply it to /usr and all subdirectories I thought of something like rpm -q --dump -R /usr. But before doing so I looked up the man for rpm and realized that the parameter -R has a different meaning here.

So my question is if it is sufficient to type something like rpm -q --dump /usr or should I better use rpm -q --dump -a?

19

Just my 2 cents.

When you would have re-installed the system (keeping your /home of course) you would have ben running again yesterday IMHO.

That is still possible.

20

It needs RPM name(s) so it should be “-a”. But if you already executed these commands and nothing changed this is unlikely to help; it should have already set all permissions RPM was aware of.

Hmm … try to execute commands in reverse order. My theory is that --setugids changes ownership, which resets SUID/SGID flag. In this case subsequent --setperms would set them correctly. I.e. first --setugids and then --setperms.