Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!nbires!hao!noao!arizona!whm
From: whm@arizona.UUCP
Newsgroups: comp.bugs.4bsd
Subject: silent failures in su -- really csh bug in 4.3+NFS
Message-ID: <1530@megaron.arizona.edu>
Date: Mon, 23-Feb-87 21:56:45 EST
Article-I.D.: megaron.1530
Posted: Mon Feb 23 21:56:45 1987
Date-Received: Fri, 27-Feb-87 05:42:19 EST
Organization: U of Arizona CS Dept, Tucson
Lines: 43
Keywords: su csh 4.3BSD

If you try to start csh in a directory that you can't do a pwd in (i.e. a
directory where getwd fails), csh silently fails to start.  Try this:

	cd /tmp
	mkdir x
	cd x
	chmod 0 .
	csh -c date

The usual place where this bug shows up is in su -- you're in a directory
that user X can't read and when you "su X" you find that you're still you
and not X.  I thought this problem had been fixed at some point, but it's
definitely in 4.3+NFS from Mt. Xinu and probably in UCB's 4.3 as well.

In sh.dir.c in dinit(), there's code:

	else {
		cp = getwd(path);
		if (cp == NULL) {
			(void) write(2, path, strlen(path));
			exit(1);
		}
	}

However, 2 isn't a valid file descriptor at this point (allegedly, 0-2 are
good only when didfds is non-zero and it's zero at this point).  My fix is:

	else {
		cp = getwd(path);
		if (cp == NULL) {
			strcat(path, " -- can't start new shell\n");
			(void) write(SHDIAG, path, strlen(path));
			exit(1);
		}
	}

Just s/2/SHDIAG/ is enough to get some output, but the error message -- the
return value from getwd -- doesn't end with a newline and "getwd: can't
stat ." might not be enough to alert a novice user to the problem.

					Bill Mitchell
					whm@arizona.edu
					{allegra,cmcl2,ihnp4,noao}!arizona!whm