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