HP-UX groups/newgrp quirk

Has anyone ever seen this situation in HP-UX:

/etc/group:
lp::7:root,lp,trnadm

trnadm# groups
bin users

As user trnadm, I'm in the groups file under the group lp, however when I run the groups command on the command line, I don't show up in that group. When I try to use the priviledges of that group I get denied. However, when I use the newgrp command, I'm suddenly in that group. I thought that if I was in the groups file in a specific group, I'm always a part of that group. I've never used the newgrp command before. Does anyone here have experience with it? How does it work? Is it something to configure on install?

The newgrp command basically switches your current group-id to a new group-id and only if you are in said group. If you're not, you'll get a failed message similar to 'Sorry'. What appears to be the case is that the groups command for you is a buggy output as you belong in the group lp but it doesn't show. If newgrp works though, you're good to go.

Disclaimer: I haven't worked too much with it and I don't know exactly why you'd be failing on a group-based job when you have access to it (permissions, etc).

Let me know if you need more help though! HPUX is my thing!

Thanks for your reply, Vorlin. It seems that I'm dealing with a bug of some kind. It's like HP-UX is only recognizing my effective GID which is the GID for the users group, but I was under the impression that most versions of UNIX allow for up to 16 concurrent groups at a time. This system won't let me execute anything with lp group permissions unless I make lp my effective GID using the newgrp command. Very strange. I put in a ticket to our engineers. I'll post the results of their analysis. Thanks again, though. Perhaps you can answer me this, though: On HP-UX do you have to use the groupadd command to add someone to the groups file? Most systems will let you simply edit the /etc/groups file to add an entry as long as the GID you choose doesn't conflict with any others, just like the /etc/passwd file doesn't have to be modified with useradd. I know that BSD wants you to use vipw to edit the password file, because the actual file is master.passwd, but I've never heard of anything like that required for HP-UX. Any ideas?

roswell1329,

Most welcome! In response to your question, you do NOT have to use groupadd. In fact, groupadd is not even used for adding users to any given group as it used to add new groups to the system (you have the option of assigning a new GID at creation). What you're refering to is usermod.

Examples:

Add a new group called foo with a gid of 150
# groupadd -g 150 foo

Add user blargho to the system with the primary group of users and the secondary as foo
# useradd -m -c "Blargho user" -g users -G foo blargho

As for vipw, that's the safest way to edit the passwd file as it creates a tmp file in /tmp and edits that rather than editing the only master copy. If you blow it up, nobody cares because it's a temp file. When you save it with vipw, it writes a backup of the current one.

Hopefully this helps out!

Thanks again, Vorlin. As it turns out, the security application I was using to switch users to the trnadm account was doing some screwy things. The application is supposed to be a more robust version of 'su' with some additional logging features. Unfortunately, the way it is implemented, it retains the login environment of your personal logon. In the case above, it turns out that my personal account was in the bin and users groups, so when I ran the command 'groups' after I switched users to trnadm, it just reported the groups that my personal account was in. My effective GID was also retained, so I had to use 'newgrp' to move the trnadm account into it's proper place.

What a mess! I'm really beginning to hate all these 3rd party root-management applications. What's wrong with 'sudo'? (other than the fact that it also is a 3rd party root-management application) :D

Anyway, thanks again.

Ahhh, good old sudo. Todd Miller did a good job with it, I think, because it's just about the only root-management program I'd use to delegate out root-driven executables/scripts/functions/etc. Implementation is the biggest thing as most just ./configure && make && make install and let it go at that.

One thing you might do is this, as a fix for the group problem regarding trnadm:
usermod -g users -G lp trnadm

That'll put users as the primary group and in the lp group as secondary. You should be good to go after that. As far as sudo is concerned, it's a good product. Be careful you're not using HP's version because their depot release had a binary that ate up memory constantly with every command executed (even blank returns) while under a sudo'd session. The latest is 1.6.6 and can be gotten at www.courtesan.com .