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

Pioneer Support
1

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.

2

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.

3

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.

4

Is the user in the admin group?

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

@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.

6

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.

7

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.

8

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
1 Like
9

Think I’ve just run into the same issue. Suddenly not in the sudoers file over SSH but still admin in Plinth. Here’s the output from the above commands if it’s still any use so long after:

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: ou=users,dc=thisbox
objectClass: top
objectClass: organizationalUnit
ou: users

dn: uid=zzz,ou=users,dc=thisbox
objectClass: account
objectClass: posixAccount
cn: zzz
uid: zzz
uidNumber: 10003
gidNumber: 100
homeDirectory: /home/zzz
loginShell: /bin/bash
gecos: zzz
description: User account
userPassword:: e1NTSEF9MnZPYXVTWGJ6WWMrbGl2TnA1NmNQR3lGVktCNEtqaHY=

dn: uid=user1,ou=users,dc=thisbox
objectClass: account
objectClass: posixAccount
cn: user1
uid: user1
uidNumber: 10001
gidNumber: 100
homeDirectory: /home/user1
loginShell: /bin/bash
gecos: user1
description: User account
userPassword:: removed by me

dn: uid=user2,ou=users,dc=thisbox
objectClass: account
objectClass: posixAccount
cn: user2
uid: user2
uidNumber: 10002
gidNumber: 100
homeDirectory: /home/user2
loginShell: /bin/bash
gecos: user2
description: User account
userPassword:: removed by me

dn: uid=bella-north,ou=users,dc=thisbox
objectClass: account
objectClass: posixAccount
cn: bella-north
uid: bella-north
uidNumber: 10000
gidNumber: 100
homeDirectory: /home/bella-north
loginShell: /bin/bash
gecos: bella-north
description: User account
userPassword:: removed by me

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: ou=groups,dc=thisbox
objectClass: top
objectClass: organizationalUnit
ou: groups

dn: cn=vpn,ou=groups,dc=thisbox
objectClass: posixGroup
cn: vpn
gidNumber: 10004
description: Group account
memberUid: user1

dn: cn=admin,ou=groups,dc=thisbox
objectClass: posixGroup
cn: admin
gidNumber: 10001
description: Group account
memberUid: bella-north
memberUid: zzz

dn: cn=minidlna,ou=groups,dc=thisbox
objectClass: posixGroup
cn: minidlna
gidNumber: 10003
description: Group account
memberUid: user1
memberUid: user2

dn: cn=feed-reader,ou=groups,dc=thisbox
objectClass: posixGroup
cn: feed-reader
gidNumber: 10002
description: Group account
memberUid: user1

dn: cn=freedombox-share,ou=groups,dc=thisbox
objectClass: posixGroup
cn: freedombox-share
gidNumber: 10000
description: Group account
memberUid: user1
memberUid: user2

10

Can you open the sudoers file from the terminal in Cockpit?

sudo visudo
11

Thanks for the reply but I’ve already fixed it following the advice in the thread to add a new admin user and use that account to re-add my original account to admin. Just thought it might be helpful to report it since the last post asked for reports! :slight_smile: