According to Paul Ripke:
>
>I've tripped over this at work, and brief investigation has shown
>that the following "feature" occurs with NetBSD, AIX and Solaris,
>while DEC UNIX (Tru 64, whatever), 

This is what should happen...

>SCO and Linux are unaffected.

If this is true, then it is a bug with them...

>I don't have access to any other breeds to test; I don't see it as
>a problem, I was just after a brief explanation from someone in
>the know

OK, this is how I think it works.  You have a mount point called /foo
with a mode of 111, when you mount a file system over the top of /foo
the root of the new file system becomes /foo.  If you cd to foo then
the root of the new file system is . and the permissions you see are
the permissions for the root of the mounted file system.  When you
want to examine .. from /foo you need to read the inode of the file
system that contains the mountpoint (i.e. you need to access the /foo
directory as it was prior to mounting the /foo file system on it) to
find the parent directory.  This is where you come unstuck, the
permissions on the /foo mount point directory are such that you are
not allowed to do so because of the permissions on the underlying
directory - hence the permission denied.

-- 
===============================================================================
Brett Lymn, Computer Systems Administrator, BAE SYSTEMS
===============================================================================