Need to use newgrp or equivalent
David Elliott
dce at mips.COM
Sat Nov 5 03:43:28 AEST 1988
In article <1843 at cbnews.ATT.COM> lml at cbnews.ATT.COM (L. Mark Larsen) writes:
>Assuming you are using the standard /bin/sh, turning on the setuid bit
>of /bin/newgrp is unlikely to have any impact since the newgrp command
>is a built-in command (also built-in in ksh). Without further details,
>it is hard to say what might be the problem. Suffice it to say that
>newgrp works fine in SysV UNIX.
This is not correct in System V.3, System V.3.1, or any other sh I've
ever worked with. The builtin newgrp command simply execs the newgrp
command (this is done so that the current shell is replaced by a new
one with the new gid set), so turning on the setuid bit and making the
owner root will have a major impact.
If the system in question is a MIPS system running UMIPS (SysV UNIX
with BSD enhancements), /bin/newgrp does indeed need to be changed to
mode 4655 and owned by root (we accidentally shipped it with mode 555
and owner bin). Also, if you are using csh, you will lose history.
This is fixed in the next release. The release after that will have
full BSD group support.
Now, the reasons you may be denied access with 'Sorry' printed are:
1. No password entry for your current uid.
2. Can't setgid() to the new gid or setuid() to your real
uid.
3. You aren't in the group member list and there is no group
password. If you are sure that you *are* in the list, make
sure your group entry is formatted correctly (no missing
password field, usernames separated by commas and no
whitespace!).
4. You aren't in the group member list, but there is a group
password and you give it incorrectly.
--
David Elliott dce at mips.com or {ames,prls,pyramid,decwrl}!mips!dce
More information about the Comp.unix.wizards
mailing list