msc@qubix.UUCP (Mark Callow) (11/26/83)
One cause of this problem is that the PARENT of the directory you are in
does not have world read permission. I.e., mode 4 is not set. The same
thing happens with certain uucp variants and with inews. The problem
is that these programs run suid something else (such as uucp and newsmgr)
and they call pwd to determine the current working directory. pwd,
by this time running as user uucp (for instance) attempts to open the
parent directory for reading fails, since uucp doesn't have read permission
on the directory, leading to these error messages.
The problem arose here because we have a hierarchy in our directories
based on company departments and everyone's parent directory is owned
by her department, in her department's group and is mode 751.
My solution was to make pwd run suid root.
--
Mark Callow, Saratoga, CA.
...{decvax,ucbvax,ihnp4}!decwrl!
...{ittvax,amd70}!qubix!msc
decwrl!qubix!msc@Berkeley.ARPAhoney@princeton.UUCP (code 101) (11/27/83)
it's a harmless, if annoying bug in uux. (it wants your working directory in case you are uux'ing something to run on a remote with an argument file in `.' on the local host, which you're not, since mail uux'es a remote rmail that reads from stdin [look ma, i can verb any word!].) not to worry, we fixed it (and [to quote lauren ... ahem] everything else) in the uucp of the future. peter honeyman
Pucc-H:Physics:suitti@CS-Mordred.UUCP (12/01/83)
When using mail to send to someone on another machine, I get the following messages: pwd: Can't stat directory.: Permission denied can't get working directory; will try to continue Naturally, neither message is in /usr/ucb/mail itself. The first line is "pwd", Print Working Directory. Is your system new? Did you recently have your file systems changed? I ran into a bug like it, not too long ago. It has to do with mounting file systems. A file system is mounted on a directory of another mounted file system. On my system (2.8 bsd, pdp-11/44), all file systems are mounted on directories in the root file system. Once you mount a file system, the root directory of the file system sort of has two inodes that point to it. One is the inode in the system root file system, and the other is the inode for the root directory in the mounted file system. If the protection codes are differant, weirdness can happen. The stat(2) system call, as implemented in the kernel seems to use the inode in root file system. Most other protection references use the protections of the mounted file system. "pwd" uses stat(2) to do all of it's work. How to check if this is the case: Bring the system to single user. Check the protecions (ls -ld) of the directory on the root file system. Mount the file systems in question. Check the protections again. Be sure the check owners and groups as well (ls -ldg). Solution: Just set the owner, group owner, and protections identicle. Longer term solution: New releases could be checked for this inconsistency. I'd hardly term it a serious bug. Stephen Uitti (Purdue physics site manager) UUCP: pur-ee!Physics:suitti, purdue!Physics:suitti INTERNET: suitti @ pur-phy.UUCP
wls@astrovax.UUCP (William L. Sebok) (12/02/83)
Actually the pwd error message is usually caused by being in a directory whose
path from the root is not world readable (for example, a subdirectory of a
private correspondence directory). pwd tries to reconstruct your full
directory name my starting at the root and working downward. In mail or
in inews pwd is executed by a program setuid to a uid other than root. Then
pwd just does not have the privileges to do its job properly. We solved it
here by making pwd a suid to root program. I haven't been able to think of
any security holes this would cause.
--
Bill Sebok Princeton University, Astrophysics
{allegra,akgua,burl,cbosgd,decvax,ihnp4,kpno,princeton}!astrovax!wls