david@varian.UUCP (David Brown) (08/20/86)
I've been having problems using tip on 4.3BSD. When I try to use any
tilde command that requires forking a shell (~!, ~$, etc.), I get:
/bin/csh: permission denied
My environment variable SHELL is set to /bin/csh; when I change this
to /bin/sh, the subshell mechanism works. I've temporarily removed
my .cshrc file; this didn't help. I've looked at the code
where the fork and execl() are done (/usr/src/usr.bin/tip/cmds.c) and
don't see anything unusual.
The permissions on /bin/csh look normal (755).
Has anyone else noticed this problem? Any help would be appreciated.
Thanks.
--
David Brown (415) 945-2199
Varian Instruments 2700 Mitchell Dr. Walnut Creek, Ca. 94598
{zehntel,dual,amd,fortune,rtech,lll-crg,rtgvax,ptsfa,csi}!varian!davidjbc@ghostwheel.UUCP (John Chambers) (08/22/86)
Let's suppose you have the typical setuid/gid tip.
Cf. /usr/src/usr.bin/tip/tip.c at or around line 137
.
.
gid = getgid();
egid = getegid();
uid = getuid();
euid = geteuid();
setregid(egid, gid);
setreuid(euid, uid);
.
.
and /usr/src/bin/csh/sh.c at or around line 209
.
.
if (!batch && (uid != geteuid() || getgid() != getegid())) {
errno = EACCES;
child++; /* So this ... */
Perror("csh"); /* ... doesn't return */
}
.
.
We argued that tip should reset uid's before exec'ing a shell and that
we like csh as it is, and hence added something to the effect of:
setregid( gid, gid );
setreuid( uid, uid );
in the suitable places in /usr/src/usr.bin/tip/cmd.c ....
--------
J.B. Chambers
snail: MCC/Database, P.O. Box 200195, Austin TX 78720 USA
arpa: jbc@sally.utexas.edu, db.chambers@mcc.com
uucp: {gatech,harvard,ihnp4,seismo,pyramid,...}!ut-sally!{,ghostwheel!}jbc
voice: 512 343 0860ddl@husc6.HARVARD.EDU (Dan Lanciani) (08/22/86)
In article <600@varian.UUCP>, david@varian.UUCP (David Brown) writes: > I've been having problems using tip on 4.3BSD. When I try to use any > tilde command that requires forking a shell (~!, ~$, etc.), I get: > > /bin/csh: permission denied > This is a "feature" of the C-shell. If on interactive startup it finds that its real uid != its effective uid or its real gid != its effective gid it prints this unhelpful message and exits. I assume this is supposed to prevent evil hackers from getting privileged shells. Of course, all evil hackers use sh so nothing is gained by the hack. It would make much more sense to fix the program (tip in this case) than to break the shell. Note that this also makes setuid C-shell scripts fail. Dan Lanciani ddl@harvard.*
chris@umcp-cs.UUCP (Chris Torek) (09/14/86)
In article <3000009@inmet> nrh@inmet.UUCP writes: >Subject: Re: Orphaned Response Someone at inmet should look into installing the current version of notesfiles, to help eliminate the `Orphaned Response' plague. [changes to tip:] >+ setuid(getuid()); /* Avoid "permission denied" problem */ >+ setgid(getgid()); /* ditto? */ If you intend to set both user and group IDs, you should do this in the other order. This is likely to work for tip (which is not setgid) or under 4.2/4.3BSD (where setregid allows either egid or rgid to be specified for both), but breaks on V7ish systems (including 4.1BSD). As to the original bug, I have no idea what is wrong; we do not use tip. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu