getcwd() problem on OSR6/MP1

[Roger Cornelius]

I'm seeing weird behaviour from getcwd() on OSR6/MP1. It fails
inexplicably in some cases, with errno of EACCES. I noticed the
problem with the mutt mailer, but here's a short program I used to test
with:

/* /tmp/getcwd.c */
#include <unistd.h>
main()
{
char *d;
if ((d = getcwd(NULL, 512)) == NULL)
perror();
else
printf("dir = %s\n", d);
}

Here's a typescript which illustrates the problem. I've added blank
lines to make it readable. Note that the test program fails when cd'd
to /u2 if invoker is not root.

Script started on Fri Feb 24 16:20:39 2006
$ id
uid=201(rac) gid=101(special) groups=101(special),50(group)

$ ls -ld /u1 /u2
drwxr-xr-x 11 root sys 2048 Aug 22 2005 /u1
drwxr-xr-x 5 root sys 96 Aug 15 2005 /u2

$ getacl /u1 /u2
# file: /u1
# owner: root
# group: sys
user::rwx
group::r-x
class:r-x
other:r-x

# file: /u2
# owner: root
# group: sys
user::rwx
group::r-x
class:r-x
other:r-x

$ df
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/root 7167998 2413744 4754254 34% /
/dev/boot 40959 6787 34172 17% /stand
/proc 0 0 0 - /proc
/dev/fd 0 0 0 - /dev/fd
/dev/_tcp 0 0 0 - /dev/_tcp
/dev/u 3071998 2314044 757954 76% /u
/dev/u1 24162644 23864852 297792 99% /u1
/dev/u2 8867870 2078538 6789332 24% /u2
/processorfs 0 0 0 -
/system/processor
/var/tmp 524288 24 524264 1% /var/tmp

$ cd /u1
$ pwd
/u1

$ /tmp/getcwd
dir = /u1

$ cd /u2
$ pwd
/u2

$ /tmp/getcwd
Permission denied

$ su
Password:

# /tmp/getcwd
dir = /u2
# $

script done on Fri Feb 24 16:21:50 2006

I did not include it above, but the test program works correctly when
cd'd to /u. The only difference I can see is that /u2 is on a second
disk. Filesystems are all vfxd.

Anyone have any ideas what might be wrong?

[Bela Lubkin]

Roger Cornelius wrote:

Yes! This goes back to a buggy behavior I remember seeing on Xenix and
possibly SCO Unix 3.2.0, maybe even a little later, but it was
eventually fixed.

It's a mounted filesystem. Current working directory is discovered in
reverse order (from leaf to root). The path from (say) /u2/foo/ is:
/u2/foo; /u2/. (the root of the mounted filesystem); /u2 (the
mounted-on directory on the root filesystem); /. While the filesystem
is mounted, you can only examine three of those. You can't see the
permissions of the mounted-on directory.

Try:

# umount /u2
# ls -ld /u2
[I predict it will have perms that deny world-execute == world-search]
# chmod 755 /u2
# mount /u2

Now all is well again. Right?

I say "buggy behavior" but I'm not sure I can prove that the perms of
the underlying (mounted-on) directory _should_ be ignored. I know that
OSR5 does ignore them, and my guess is that OSR6 doesn't, as
demonstrated on your system.

>Bela<

[Roger Cornelius]

Yes, that was exactly it. Thanks once again for your kind
illumination. It would never have occurred to me to check this.