tomm@voodoo.UUCP (Tom Mackey) (11/02/88)
I do most of my work on a SysV based system with BSD enhancements, and need to be able to switch my gid only to another group. I have added my name to the list of users in the other group in /etc/group, and even made newgrp(1m) suid to root, but I still get "sorry" as the reply from newgrp. It seems to me I fought this battle a few years ago, but never found a solution before it became a non-problem. Do any of you have any hints as to what I need to do to change my gid to another group and back again while the rest of my environment stays the same? If this has been thouroughly thrashed over, I appologize... I saw nothing of help in the last month's postings. -- Tom Mackey (206) 234-7724 (wk) Boeing Computer Services ....uw-beaver!ssc-vax!voodoo!tomm M/S 6M-17, P.O. Box 24346, Seattle, WA 98124-0346
lml@cbnews.ATT.COM (L. Mark Larsen) (11/03/88)
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. L. Mark Larsen lml@atlas.att.com att!atlas!lml
dce@mips.COM (David Elliott) (11/05/88)
In article <1843@cbnews.ATT.COM> lml@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@mips.com or {ames,prls,pyramid,decwrl}!mips!dce
guy@auspex.UUCP (Guy Harris) (11/05/88)
>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). A built-in command that "exec"s "newgrp" as its last act; unless your shell is itself set-UID, it's unlikely to be able to change your effective group ID (unless your OS lets you do this without root privileges, and most UNIX versions will, at most, let you change it to match your real group ID or, in systems that support it, your saved set-group ID). So turning on the set-UID bit *could* have an impact.
peter@ficc.uu.net (Peter da Silva) (11/05/88)
In article <1843@cbnews.ATT.COM>, lml@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). If you stop to think about this, you'll see that newgrp can't be a builtin in the shell, unless your shell runs setuid root. What is builtin is a command to exec newgrp (instead of forking and execcing). This, in fact, turns out to be fairly poor behaviour. Here we use a command that works like 'su' instead of like 'login', letting you pop back to your old group id (and environment) when you're done. Implementation is an excersize left to the reader... -- Peter da Silva `-_-' Ferranti International Controls Corporation "Have you hugged U your wolf today?" uunet.uu.net!ficc!peter Disclaimer: My typos are my own damn business. peter@ficc.uu.net
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (11/05/88)
In article <1843@cbnews.ATT.COM> lml@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. /bin/newgrp is the correct place to look. If it is not SUID root, then it is guaranteed to not work. The shell treats the newgrp command specially by exec'ing /bin/newgrp without fork'ing first. -rws--x--x 1 root bin 13361 Apr 13 1987 /bin/newgrp That is the ls -l output for /bin/newgrp here. Your permissions should be similiar. Everything else is probably different ... Your milage may vary ;-) -- John F. Haugh II +----Make believe quote of the week---- VoiceNet: (214) 250-3311 Data: -6272 | Nancy Reagan on Richard Stallman: InterNet: jfh@rpp386.Dallas.TX.US | "Just say `Gno'" UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
lml@cbnews.ATT.COM (L. Mark Larsen) (11/08/88)
In article <7668@dunkshot.mips.COM> dce@dunkshot.UUCP (David Elliott) writes: #In article <1843@cbnews.ATT.COM> lml@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. Hummm... Can I plead temporary stupidity? I can't believe I wrote that. L. Mark Larsen
allbery@ncoast.UUCP (Brandon S. Allbery) (11/11/88)
As quoted from <1843@cbnews.ATT.COM> by lml@cbnews.ATT.COM (L. Mark Larsen): +--------------- | 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. +--------------- newgrp is built into the shell, yes... but only so that the shell will exec it instead of forking. It DOES require root privileges to change your gid (BSD equivalent: add entries to your group vector) for the same reason it takes root privileges to change your uid. Assuming non-BSD groups, make sure the group line in /etc/groups doesn't have a password. "newgrp" enforces passwords, although there is no way to set them aside from kluging with "passwd" and "vipw". (Note that group passwords are generally considered to be "fake security", i.e. they don't really buy you anything security-wise.) ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.