[SOLVED] Foo is not in the sudoers file. This incident will be reported

Hi all.

I’m getting this message for my main user (and only one besides the system user fbx) when I try any sudo command. It’s been a long time since I last logged into the freedombox, but I’m pretty sure the user was part of the sudo group.

$ getent group sudo                                                                                                                                                                                                                                             
sudo:x:27:fbx
$ id                                                                                                                                                                                                                                                            
uid=10000(foo) gid=100(users) groups=100(users),118(_tor-plinth)
$ cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Is there an explanation the user is no longer a sudoer? How do I re-add him to the group given root doesn’t have a password set?

Best regards.

This information is in LDAP. Perhaps the LDAP daemon is not running properly. Check status:

systemctl status slapd
systemctl status nslcd
systemctl status nscd

Rebooting the machine might even set things right.

I had already rebooted before posting. Didn’t fix things.

To answer to your suggestion, this is the output of the 3 commands:

$ systemctl status slapd
? slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)
Loaded: loaded (/etc/init.d/slapd; generated)
Active: active (running) since Wed 2019-08-14 18:13:25 CEST; 2h 38min ago
Docs: man:systemd-sysv-generator(8)
Process: 736 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS)
Tasks: 6 (limit: 2304)
Memory: 11.5M
CGroup: /system.slice/slapd.service
└─839 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d

? nslcd.service - LSB: LDAP connection daemon
Loaded: loaded (/etc/init.d/nslcd; generated)
Active: active (running) since Wed 2019-08-14 18:35:19 CEST; 2h 16min ago
Docs: man:systemd-sysv-generator(8)
Process: 854 ExecStart=/etc/init.d/nslcd start (code=exited, status=0/SUCCESS)
Tasks: 6 (limit: 2304)
Memory: 2.0M
CGroup: /system.slice/nslcd.service
└─932 /usr/sbin/nslcd

$ systemctl status nscd
? nscd.service - Name Service Cache Daemon
Loaded: loaded (/lib/systemd/system/nscd.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2019-08-14 18:12:57 CEST; 2h 39min ago
Process: 297 ExecStart=/usr/sbin/nscd (code=exited, status=0/SUCCESS)
Main PID: 305 (nscd)
Tasks: 11 (limit: 2304)
Memory: 1.3M
CGroup: /system.slice/nscd.service
└─305 /usr/sbin/nscd

The ‘?’ character instead of the usual colored dot in the beginning of systemctl’s output is weird though.

Is the user in the admin group?

$ id
uid=10000(jvalleroy) gid=100(users) groups=100(users),10000(admin)

@jvalleroy, initial report contains the ouput as id as:

uid=10000(foo) gid=100(users) groups=100(users),118(_tor-plinth)

So, the user is somehow not part of the admin group but instead part of _tor-plinth group. The latter group is created when Tor is setup and FreedomBox creates a tor instance called ‘plinth’. foo should not be part of that group for any reason. At the same time foo user should have been part of admin group and is not. foo user is likely the first user created during initial setup given the UID being 10000. Strangely, this situation occurred after a bit of usage.

@kat85, are you able to login to FreedomBox web interface? Does the interface show you as administrator (you will be able to see the apps and system pages). If so, you can try to create a new user with administrator privileges and see if that user is able to do sudo and has proper information for id user2. Also could you post the output of getent group? Thanks for your patience with the issue.

Regarding your questions:

Yes, user foo has id 10000.
Yes, I can log into web iface.
Yes, I can see apps and sys pages => user is admin in plinth.
Yes, could create another administrator user foo2 and can ssh and sudo.
The output of getent group:
root:x:0:
daemon:x:1:
bin:x:2:
sys:x:3:
adm:x:4:
tty:x:5:
disk:x:6:
lp:x:7:
mail:x:8:
news:x:9:
uucp:x:10:
man:x:12:
proxy:x:13:
kmem:x:15:
dialout:x:20:
fax:x:21:
voice:x:22:
cdrom:x:24:
floppy:x:25:
tape:x:26:
sudo:x:27:fbx
audio:x:29:
dip:x:30:
www-data:x:33:
backup:x:34:
operator:x:37:
list:x:38:
irc:x:39:
src:x:40:
gnats:x:41:
shadow:x:42:
utmp:x:43:
video:x:44:
sasl:x:45:
plugdev:x:46:
staff:x:50:
games:x:60:
users:x:100:
nogroup:x:65534:
systemd-journal:x:101:
systemd-timesync:x:102:
systemd-network:x:103:
systemd-resolve:x:104:
input:x:105:
kvm:x:106:
render:x:107:
crontab:x:108:
netdev:x:109:
fbx:x:1000:
messagebus:x:110:
ssl-cert:x:111:postgres
nslcd:x:112:
ssh:x:113:
openldap:x:114:
avahi:x:115:
plinth:x:116:
systemd-coredump:x:999:
debian-tor:x:117:
_tor-plinth:x:118:foo
syncthing:x:119:
radicale:x:120:
debian-deluged:x:121:
piavpn:x:1001:
mysql:x:122:
postgres:x:123:
epmd:x:124:
ejabberd:x:125:
Debian-exim:x:126:
admin:*:10000:foo,foo2

Here I notice that user foo is part of group admin (10000).
So I went back as foo and now the output of id shows that user foo does indeed belong to group admin (10000) and I can sudo again!

I cannot explain why things are back to normal. I took no additional action since I initially posted the problem except for creating a new admin user foo2 as you proposed. Could this have triggered the fix?

BR.

Creating new user flushes the cache of nscd. However, you already rebooted the machine to that does not explain it.

I had a situation on my development machine were LDAP ‘admin’ group was deleted due to running unittests. This will lead to a situation similar to yours where user can’t login on the console but is ‘admin’ in the web interface. However, this situation is clearly not yours since adding the second user does not fix the situation for the first user. I have made the fixes to the unit tests.

Your case remains unexplained for now.

Also anyone who encounters the problem should run the following command as root user (after working around the problem) and report the output:

ldapsearch -L -L -L -Y EXTERNAL -H ldapi:/// -b ou=users,dc=thisbox
ldapsearch -L -L -L -Y EXTERNAL -H ldapi:/// -b ou=groups,dc=thisbox