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 _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
