42.2 Root password not recognised by GUI apps after chmod mistake

English Install/Boot/Login
#1

Hi all,

I recently committed a major @#&* up on my opensuse 42.2 box running kde 4.14, according to kde4-config. Intending to run

chmod -R 776 ./

as root, I ran

chmod -R 776 /

in error.

Once you’ve all finished rofl, some help recovering would be appreciated! I realised my error soon enough and caught it with Ctrl-C before it had got to e for /etc, but not before it had worked its way through /bin, /boot and /dev. By and large there seemed to have been no obviously calamitous consequences to this, but one odd side-effect is that I can no longer launch GUI apps as the root user. Specifically, I’m prompted for the root password as usual but it is not recognised.

As examples, in Konsole if I try to open a root tab I’m prompted for and enter a password, it hangs for a few seconds then the new tab disappears. With YaST, I get a Run As Root dialog box, this hangs for a few seconds then another dialog box appears including the text…

Permission denied.
Possibly incorrect password, please try again.
On some systems, you need to be in a special group (often: wheel) to use this program.

The same is true for any other GUI app that I attempt to run as root. I don’t know anything about the wheel group, but this has never been a problem prior to my, ahem, incident.

Fortunately, I can still access root by running

sudo su -

and the password is accepted, so I know the password itself is not the issue, and for this reason I suspect that I might have knocked out the executable bit on some helper app that acts as an agent for GUI programs but have no idea what that might be, or if I’m just plain wrong. I wondered if it might be kdesu, but I can still run this at the command line and I get the same Run as Root dialog box scenario described above.

So, I can work around a lot of things at the command line but not being able to access YaST is a severe handicap (YaST in text mode is not much fun). Does anyone have any ideas what I can do to fix this, or whether it would be fixed if I upgraded to 42.3?

Also worried about any other unseen consequences, vulnerabilities that might have been opened up etc. Any thoughts welcome.

Thanks
Rob

#2

Did you use the btrfs file system and can you do a rollback with snapper?

#3

Maybe to obvious, but let us just shoot in the dark:
Did you check ownership/permision of the shadow file?

boven:~ # l /etc/shadow
-rw-r----- 1 root shadow 1129 Mar 14  2017 /etc/shadow
boven:~ #

It is one of those where changing permissions as you did will create problems.

#4

This command should fix most important file permissions:

sudo chkstat --system

Feel free to ask for further help in case you get errors.

#5

Excellent advice all round. It looks like I might have had a btrfs image from February I could’ve used as a last resort but it looks like chkstat has done the trick. YaST and kdesu password prompts are now accepting the password. Looks like it may have been related to /etc/shadow, though not permissions, the group was incorrectly set to root. Not sure how that came about, maybe there was something else I’d done which knocked it out. Thanks for the help folks.

eagle:/bin # snapper list
Type   | #   | Pre # | Date                     | User | Cleanup | Description           | Userdata     
-------+-----+-------+--------------------------+------+---------+-----------------------+--------------
single | 0   |       |                          | root |         | current               |              
single | 1   |       | Sun Apr 30 22:38:20 2017 | root |         | first root filesystem |              
single | 2   |       | Sun Apr 30 23:54:43 2017 | root | number  | after installation    | important=yes
pre    | 260 |       | Fri Dec 15 00:08:43 2017 | root | number  | yast sw_single        |              
pre    | 263 |       | Fri Dec 15 23:56:28 2017 | root | number  | zypp(y2base)          | important=no 
post   | 264 | 263   | Fri Dec 15 23:56:29 2017 | root | number  |                       | important=no 
post   | 265 | 260   | Sun Dec 17 22:53:01 2017 | root | number  |                       |              
pre    | 266 |       | Sat Feb 24 00:01:14 2018 | root | number  | yast sw_single        |              
post   | 267 | 266   | Sat Feb 24 00:03:11 2018 | root | number  |                       |              
pre    | 268 |       | Sat Feb 24 00:11:28 2018 | root | number  | yast sw_single        |              
pre    | 271 |       | Sat Feb 24 00:22:20 2018 | root | number  | zypp(y2base)          | important=no 
post   | 272 | 271   | Sat Feb 24 00:22:33 2018 | root | number  |                       | important=no 
post   | 273 | 268   | Sat Feb 24 00:23:10 2018 | root | number  |                       |              
eagle:/bin # l /etc/shadow
-rw-r----- 1 root root 1331 Nov 12  2017 /etc/shadow
eagle:/bin # sudo chkstat --system
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 /var/log/btmp to root:root 0600. (wrong owner/group root:utmp)
setting /etc/shadow to root:shadow 0640. (wrong owner/group root:root)
setting /etc/ppp/ to root:dialout 0750. (wrong owner/group root:root)
setting /usr/bin/su to root:root 4755. (wrong permissions 0755)
setting /usr/bin/mount to root:root 4755. (wrong permissions 0755)
setting /usr/bin/umount to root:root 4755. (wrong permissions 0755)
setting /etc/texmf/ls-R to root:mktex 0664. (wrong owner/group root:root)
#6

No idea why that would have happened, but the real reason for your problem is rather the missing suid bit on /usr/bin/su:

setting /usr/bin/su to root:root 4755. (wrong permissions 0755)

Without it su will run as unprivileged user, and cannot access /etc/shadow anyway (even if its group is correct).

kdesu does use su to gain root privileges… :wink: