ID results different depending on who asks

Question

I have userX who has realtime privileges thorugh the realtime group. I wanted to give that user admin privileges so I switched to root

~>su root

and ran

#>usermod -a -G root userX

After a brief delay I got back to the prompt and tested the effect.

#>id userX
#>uid=1000(userX)  gid=0(root) groups=0(root),1001(realtime)

So it would appear that I was successful. I exited and tested my new admin by adding a dummy user.

#>exit
~>useradd BSD
bash: /usr/sbin/useradd: Permission denied

Something is wrong. I tried verifying my group membership and it gave me a different answer.

~>id
~>uid=1000(userX)  gid=1001(realtime) groups=1001(realtime) contextunconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

So, I need to know why my user says it is not part of root and root says the user is. What am I missing?

Answer 1

What's happening?

The list of groups a user is in is only set at login (and possibly modified by using the rarely used sg command, but that only works if there is a group password set for that group). If that user logs out, then logs back in, they should then see themselves in that group. However, being in the group with GID 0 ('root' on most Linux systems, 'wheel' or 'adm' on most non-Linux systems) is not the same as having administrative privileges, and is in fact a bad idea from a safety perspective.

Why is this not the same as administrative priveleges?

The root user (UID 0) is special. The root group (GID 0, called wheel on many non-Linux systems for historical reasons I cannot seem to find) isn't. Your user will be able to access files owned by the root group, but probably not much else. This is a somewhat complicated distinction, but is a very important one.

Why is this a bad idea?

This is a bad idea for pretty much the same reason that running as the root user all the time is a bad idea. You're always one mistake away from making the system unusable (on most Linux systems for example, being part of the root group means you can trivially make the system unbootable because you can delete things out of /boot).

What's the correct (and safe) way to give this user administrative privileges?

If possible, set up sudo, doas or whatever other privilege elevation tool other than su is present on your system to allow them access. If you have no such tool other than su, install one (I would suggest sudo, it's the most widely used and therefore one of the easiest to learn because there's lots of documentation). If that too is not an option, then just elevating through su when you need to do admin tasks is the correct option (although do be careful doing so, as su does not properly reset the environment for commands called through it).