su: group not found: root

michal.sviba · Oct 23, 2023

su and su - and su -m do the same. And those files .cshrc /etc/login.conf was first what I was checking. nothing suspicious

.
As I wrote, same problem has su sudo and sshd

T-Aoki · Oct 23, 2023

Just to be sure. What about your PATH environment variable?
If you installed linux su and it appears earlier than FreeBSD's one, Linux version of su is executed (via linuxulator) and possibly want group "root".

michal.sviba · Oct 23, 2023

T-Aoki said:
Just to be sure. What about your PATH environment variable?
If you installed linux su and it appears earlier than FreeBSD's one, Linux version of su is executed (via linuxulator) and possibly want group "root".

Unfortunately same result when ima using /usr/bin/su -.

Code:

#md5sum /usr/bin/su
6b36a9ff80867fb4bee511d5af4fc31d  /usr/bin/su

VladiBG · Oct 23, 2023

You can also check all <dot> files in the /root/ directory like /root/.cshrc /root/.profile /root/.login ...etc to see if any of them referencing to the group root.

michal.sviba · Oct 23, 2023

Nothing suspicious is in dot-files. I'm mostly fine with defaults + bindkey.

Problem is also when I'm going back from root to normal user su - michal. So it is not problem just for root user.

Oct 23 15:15:44 x su[26165]: group not found: michal
Oct 23 15:15:48 x su[26170]: group not found: root
Oct 23 15:15:48 x syslogd: last message repeated 1 times
Oct 23 15:15:48 x su[26171]: michal to root on /dev/pts/0

SirDice · Oct 23, 2023

Do they all have csh(1)/tcsh(1) set as their shell? Did you check /etc/csh.cshrc, /etc/csh.login? Starting to grasp at straws here.

Erichans · Oct 23, 2023

michal.sviba said:
Code:

root@x:~ # id michal uid=1001(michal) gid=0(wheel) groups=0(wheel)

SirDice said:
Your primary group is wheel, that's not good. That should be 'michal'. You probably messed up with pw usermod trying to add the wheel group.

I had these same "messed up" setting on 12.4-RELEASE and always had some ~~vague~~ unexplainable errors when using startx XFCE (did investigate & asked around, alas to no avail). As per remark from SirDice (thanks!) I changed things as shown below. Now no errors on startx.

Code:

> id eric
uid=1001(eric) gid=1001(eric) groups=1001(eric),0(wheel),601(_tss)

Perhaps/probably not related but I thought I'd mention it. Never experienced the PuTTY su - errors though, but ,as mentioned, I'm still on 12.4.

michal.sviba · Oct 23, 2023

SirDice said:
Do they all have csh(1)/tcsh(1) set as their shell? Did you check /etc/csh.cshrc, /etc/csh.login? Starting to grasp at straws here.

Those files are effectively empty (just lines commented out).

Erichans said:
I had these same "messed up" setting on 12.4-RELEASE and always had some ~~vague~~ unexplainable errors when using startx XFCE (did investigate & asked around, alas to no avail). As per remark from SirDice (thanks!) I changed things as shown below. Now no errors on startx.

Code:

> id eric uid=1001(eric) gid=1001(eric) groups=1001(eric),0(wheel),601(_tss)

Perhaps/probably not related but I thought I'd mention it. Never experienced the PuTTY su - errors though, but ,as mentioned, I'm still on 12.4.

Maybe it can helps to add new groups (michal and root). But I don't want since it was not written in any handbook. Putty is just ssh client for windows. But it's happening from another clients too.

michal.sviba · Oct 23, 2023

Can I somehow debug the command su? What files it opening is interesting.

Erichans · Oct 23, 2023

michal.sviba said:
[...]Problem is also when I'm going back from root to normal user su - michal. So it is not problem just for root user.

Have you another user ready (or can you make that so; edit: for example, add a new user) that is able to use PuTTY and su -? Does that show the same problem? What does id <another user> output?

SirDice · Oct 23, 2023

michal.sviba said:
Those files are effectively empty (just lines commented out).

Yeah, there's not much in them by default (just a bunch of comments).

michal.sviba said:
Can I somehow debug the command su?

You can try truss su -, will probably produce a LOT of output though. But it might provide some hints what it's looking for and why.

michal.sviba · Oct 23, 2023

SirDice said:
Yeah, there's not much in them by default (just a bunch of comments).

You can try truss su -, will probably produce a LOT of output though. But it might provide some hints what it's looking for and why.

truss on sick system showing ~4x more open("/etc/spwd.db" and open("/etc/group" than healthy system

I will start to investigate here:
lib/libpam/modules/pam_login_access/login_access.c: syslog(LOG_NOTICE, "group not found: %s", username);

SirDice · Oct 23, 2023

michal.sviba said:
~4x more open("/etc/spwd.db" and open("/etc/group" than healthy system

It's probably trying to resolve that non-existent group.

michal.sviba said:
I will start to investigate here:

Check /etc/pam.d/system and /etc/pam.d/passwd. Also check /etc/login.access maybe something got mangled there.

michal.sviba · Oct 23, 2023

Ok, problem founded. It's maybe not a problem since it is just NOTICE severity. The log message presents only here (not in sudo program)
https://github.com/freebsd/...login_access.c#L191

And root and michal strings are not group names, but name of logged user.

I made some changes and this is result of /etc/login.access

Code:

+:root:LOCAL
+:michal:LOCAL
+:wheel:LOCAL
+:mysql:LOCAL
+:unbound:LOCAL
+:nagios:LOCAL
+:nobody:LOCAL
+:clamav:LOCAL
-:ALL EXCEPT michal:ALL

Problem with sshd and su disappeared.
Problem with sudo is still there (Python script running my sudo commands):

Code:

Oct 23 18:14:47 x sudo[9490]: group not found: michal
Oct 23 18:14:53 x sudo[9494]: group not found: michal
Oct 23 18:15:06 x sudo[9555]: group not found: michal
Oct 23 18:15:10 x sudo[9565]: group not found: michal
Oct 23 18:15:11 x sudo[9568]: group not found: michal

michal.sviba · Oct 23, 2023

Bcs it's doing a mess in logs I do this small hack:
syslog.conf

Code:

!-sudo
*.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err   /var/log/messages
...
!sudo
*.*                                        /var/log/sudo.log

But it is still not solved

Erichans · Oct 23, 2023

michal.sviba said:
[...] And root and michal strings are not group names, but name of logged user.
[...] Problem with sudo is still there (Python script running my sudo commands):

Code:

Oct 23 18:14:47 x sudo[9490]: group not found: michal [...]

Perhaps, isn't that "group name" what is missing from your account:

Code:

root@x:~ # id michal
uid=1001(michal) gid=0(wheel) groups=0(wheel)

Compare:

Code:

# id eric
uid=1001(eric) gid=1001(eric) groups=1001(eric),0(wheel),601(_tss)
# pw groupshow eric -FP
Group Name: eric              #1001
   Members: root,_tss

SirDice · Oct 23, 2023

michal.sviba said:
The log message presents only here (not in sudo program)
https://github.com/freebsd/...login_access.c#L191

That's a start. Lets walk this back.

Code:

syslog(LOG_NOTICE, "group not found: %s", username);

So it's not the group it's looking for, it's the username that gets printed here. Confusing but I guess it's correct. Now, lets see how we get here in the first place.

Code:

if ((group = getgrnam(tok)) == NULL)

If getgrnam(3) doesn't fail (errno isn't 0), it will print the above message. The tok variable is a string that's an argument to this function:

Code:

group_match(const char *tok, const char *username)

So, now we need to find out what tok contains, in other words, what group is it trying to match/find for the user root. It's not being found, and triggers the group not found: root messages.

Kai Burghardt · Oct 24, 2023

Well, it appears the conventional scheme UID kb ⇒ (primary) GID kb is applied to root, too, in the very same fashion. Hence you see username in the code (because user name = group name). However, I don’t need to tell you guys, FreeBSD’s root user does not have a (primary) group matching the login name – it is wheel instead.

michal.sviba · Oct 25, 2023

I think the problematic module pam_login_access.so should write out what group is searching for (not just user in context).
When I own just one real user (admin) instance of FreeBSD, it's normal to have user with primary group wheel(0). And it's also normal to setup some restrictions in /etc/login.access

Here is how to reproduce writing the message to log:

/etc/login.access

+:root:LOCAL
+:michal:LOCAL
-:ALL EXCEPT michal:ALL

Run command as root: su -m michal -c id

Or I have a mistake in /etc/login.access?

twerschlein · Feb 19, 2024

What you propose is already implemented in pam_login_access.so (see pam_login_access()).
Just add the nodefgroup option to the services files in /etc/pam.d:

Code:

root@host:/etc/pam.d # grep pam_login_access.so *
other:account   required  pam_login_access.so nodefgroup
sshd:account   required    pam_login_access.so nodefgroup
system:account    required  pam_login_access.so nodefgroup
telnetd:account   required  pam_login_access.so nodefgroup

Now you have to explicitly wrap group names in parentheses in /etc/login.access:
+ : user1 user2 (group1) (group2) : ALL

I had the exact same problem as you had. /var/log/messages was spammed with group not found: root messages from sudo and sshd. Adding the nodefgroup option to the PAM module did the trick for me.

akir.akir · Apr 25, 2024

In my case it was enough to change the file named "system"

su: group not found: root

michal.sviba

T-Aoki

michal.sviba

VladiBG

michal.sviba

SirDice

Administrator

Erichans

michal.sviba

michal.sviba

Erichans

SirDice

Administrator

michal.sviba

SirDice

Administrator

michal.sviba

michal.sviba

Erichans

SirDice

Administrator

Kai Burghardt

michal.sviba

twerschlein

akir.akir