Sudo broken [Solved]

Trilby · 2016-11-07 12:14:38

Expatbrat wrote:

Surely the 13390 process is the sudo process running in gdb as in #19 above?

No, it surely isn't. Post #19 shows that a sudo process was already running in the background before you started gdb - you started gdb to connect to it. Where did that sudo process come from? Who/what spawned it, and why was it still running? Is it still running? Again, if some broken sudo process is still running that *might* be interfering with new sudo instances. Again I'm not clear on the exact mechanics of that interference, but it is the most reasonable possibility currently available, so let's test it.

Expatbrat wrote:

Does this mean sudo works in root?

Sudo doesn't need to work as root. Yes, the binary runs fine as root, but it doesn't need to do anything. The errors we have seen are because the effective uid is not 0 (root). The effective uid should be 0 as sudo is a suid binary. If you run sudo as root, then the effective uid is already 0 regardless of suid and filesystem/mount issues.

The problem here is that sudo is not getting uid 0 despite having the proper permissions, ownership, suid, and apparently being on an appropriate and appropriately mounted filesystem. Why that problem exists remains a mystery, which is why we need to keep testing. Getting rid of that 13390 process and ensuring there are no other background sudo processes would be a valuable test.

WorMzy · 2016-11-07 12:17:56

Seems like it. Which suggests the problem is with your user. Are you proloading any libraries, or running with a custom library path? Please post the output of 'env'.

Expatbrat · 2016-11-07 12:48:45

I followed the instructions here
https://bugs.archlinux.org/task/51555
to remove wins from nsswitch.conf and in su did pacman -Syu to update smbclient to the latest version and sudo now works. Samba works too.
There was a comment here
https://bbs.archlinux.org/viewtopic.php?id=218877
that removing wins from nsswitch was a dirty fix. Do I mark this as solved or is there anything more to be said? Many thanks for your help.

Expatbrat · 2016-11-07 12:51:00

In answer to WorMzy

robert@robsarch ~ $ env
XDG_VTNR=1
XDG_SESSION_ID=c1
SAL_USE_VCLPLUGIN=gen
TERMINATOR_UUID=urn:uuid:abd67497-5457-49c1-b322-e16fb268d02e
IBUS_DISABLE_SNOOPER=1
GIO_LAUNCHED_DESKTOP_FILE_PID=855
TERM=xterm
SHELL=/bin/bash
GJS_DEBUG_OUTPUT=stderr
WINDOWID=35651588
GJS_DEBUG_TOPICS=JS ERROR;JS LOG
GTK_MODULES=canberra-gtk-module
USER=robert
SSH_AUTH_SOCK=/run/user/1003/keyring/ssh
SESSION_MANAGER=local/robsarch:@/tmp/.ICE-unix/479,unix/robsarch:/tmp/.ICE-unix/479
GIO_LAUNCHED_DESKTOP_FILE=/usr/share/applications/terminator.desktop
MOZ_PLUGIN_PATH=/usr/lib/mozilla/plugins
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
MAIL=/var/spool/mail/robert
FT2_SUBPIXEL_HINTING=1
QT_QPA_PLATFORMTHEME=qt5ct
HG=/usr/bin/hg
PWD=/home/robert
EDITOR=nano
LANG=en_GB.UTF-8
CINNAMON_VERSION=3.0.7
XDG_SEAT=seat0
HOME=/home/robert
SHLVL=3
GNOME_DESKTOP_SESSION_ID=this-is-deprecated
GTK_OVERLAY_SCROLLING=0
LOGNAME=robert
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1003/bus
WINDOWPATH=1
XDG_RUNTIME_DIR=/run/user/1003
DISPLAY=:0
XDG_CURRENT_DESKTOP=X-Cinnamon
COLORTERM=gnome-terminal
XAUTHORITY=/home/robert/.Xauthority
_=/usr/bin/env
robert@robsarch ~ $

Expatbrat · 2016-11-07 12:59:01

Trilby wrote:

Expatbrat wrote:
Surely the 13390 process is the sudo process running in gdb as in #19 above?
No, it surely isn't. Post #19 shows that a sudo process was already running in the background before you started gdb - you started gdb to connect to it. Where did that sudo process come from? Who/what spawned it, and why was it still running? Is it still running? Again, if some broken sudo process is still running that *might* be interfering with new sudo instances. Again I'm not clear on the exact mechanics of that interference, but it is the most reasonable possibility currently available, so let's test it.
Expatbrat wrote:
Does this mean sudo works in root?
Sudo doesn't need to work as root. Yes, the binary runs fine as root, but it doesn't need to do anything. The errors we have seen are because the effective uid is not 0 (root). The effective uid should be 0 as sudo is a suid binary. If you run sudo as root, then the effective uid is already 0 regardless of suid and filesystem/mount issues.
The problem here is that sudo is not getting uid 0 despite having the proper permissions, ownership, suid, and apparently being on an appropriate and appropriately mounted filesystem. Why that problem exists remains a mystery, which is why we need to keep testing. Getting rid of that 13390 process and ensuring there are no other background sudo processes would be a valuable test.

I think I would have to downgrade smbclient again to reproduce the problem. pgrep -f sudo now gives me nothing. Is it necessary for the greater good?

Trilby · 2016-11-07 14:19:38

Expatbrat wrote:

Is it necessary for the greater good?

Not at all. If you're bored it might be a fun exploration - but persistent or pervasive problems are much more deserving of extended diagnostic effort than are one-off oddities. Something went wrong with your system, now it's all better. As long as the problem doesn't return and others aren't affected, I don't see much benefit in digging further.

That said, this *might* be a symptom of something being off in your samba set up. I know next to nothing about samba other than it allows file sharing and mounting remote filesystems (I think). If you were somehow invoking a 'sudo' from a remote filesystem, or if the remote filesystem were overlaid on your root and effectively changed some mount options, then either of these could explain your symptoms.

Expatbrat · 2016-11-07 21:43:19

I only use Samba to share files. it wouldn't occur to me sudo something through Samba.
For the benefit of anyone googling their own problems, An update installed the latest version of smbclient which broke pacman so that it could not download more updates. Fixing this by downgrading smbclient to the previous version broke samba and also sudo with an obscure error. The final fix was to remove wins from nsswitch.conf and update everything including smbclient. I will mark this as solved. Many thanks to all concerned, I have learnt a lot.

Arch Linux

#26 2016-11-07 12:14:38

Re: Sudo broken [Solved]

#27 2016-11-07 12:17:56

Re: Sudo broken [Solved]

#28 2016-11-07 12:48:45

Re: Sudo broken [Solved]

#29 2016-11-07 12:51:00

Re: Sudo broken [Solved]

#30 2016-11-07 12:59:01

Re: Sudo broken [Solved]

#31 2016-11-07 14:19:38

Re: Sudo broken [Solved]

#32 2016-11-07 21:43:19

Re: Sudo broken [Solved]

Board footer