Re: groups command on SLES 9

[Bob Proulx]

Scott Gardner wrote:
> [root wesdintel28 root]# id
> uid=0(root) gid=0(root) groups=0(root)

Your current list of groups from the current process is just 'root'
and nothing more.

> [root wesdintel28 root]# id -Gn -- root
> root mqm mqbrkrs
> [root wesdintel28 root]# grep root /etc/group
> root:x:0:
> mqm:!:1000:root
> mqbrkrs:!:1001:mqm,root

But root is configured in /etc/groups to be in three groups total.

> [root wesdintel28 root]# grep ^group /etc/nsswitch.conf
> group:  compat

This means files first and NIS second, if an NIS "+" token is found in
the /etc/passwd or /etc/group files.  I will assume not for now.

Before things go too much further I have to ask, why is it important
for root to be in these other groups?  Root is the superuser on the
machine and has absolute permission for anything.  Root does not need
to be in any particular group.  It is non-root users that need to be
in particular groups to gain access to parts of the system.  Is this
problem you are seeing anything more than just cosmetic?  Do you
really need this?  If so why?

> What's the next step?  Do you think this is an initgroups/setgroups
> problem or something with telnetd?

I think it is something with telnetd.  Because previously when you
reported:

> [root wesdintel28]# su -
> [root wesdintel28]# groups
> root mqm mqbrkrs

That worked so I assume that the initgroups/setgroups is working
okay.  Which means the problem is likely somewhere in telnetd.

If I were having that problem I would pull the source to telnetd and
recompile it.  I would install my version temporarily in a local
location and redirect the inetd to start it instead of the system one.
I would do this so that I knew I was running the code I compiled.
Then I would debug this code to determine why it was not setting up
the groups from the /etc/groups file.  After determining the problem I
would restore the system version so as not to leave the system in a
hacked state.

If you were comfortable debugging code then this would be the next
step.  If not then since you reported you were using SuSE I would
report this as a bug to them on the telnetd package and if this is
confirmed as a problem then someone else would need to debug it to
root cause.  I don't have any SuSE systems of my own to do anything
more than this myself.  (I could not recreate the problem on my system
and the one SuSE system I borrowed briefly to try this on did not have
this problem either.)

Bob