RE: [RFC] Pathname Semantics with //

["David Dabbs" <david@dabbs.net>]

Before we get too far into the merits of implementation-specific pathname
resolution for paths starting with //, it seems wise to address the POSIX
implications of any duality implied by this (or any other) semantic change. 

This is the first issue raised in my original post. Gunnar Ritter also
addressed it this lkml post 
[http://marc.theaimsgroup.com/?l=linux-kernel&m=109475512921055&w=2]


POSIX demands that open() must fail with ENOTDIR if "a component of the path
prefix is not a directory." If resolving a path using alternate pathname
resolution permits files to "act as" directories, is it legal to fail with
ENOTDIR when the VFS/filesystem does not support the capability even though
the final pathname component is of type S_IFREG? 

Also open() must fail with EACCES if "search permission is denied on a
component of the path prefix..." Under normal circumstances this means no
execute permission on a /directory/ path component. What does it mean when
path prefixes may be of type S_IFREG? Does this mean that normally
non-executable files must have execute permissions set? This is an important
security issue.

BTW, a "Strictly Conforming POSIX Application"
[http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap02.html#tag_
02_02_01]

#Shall accept any implementation behavior that results from actions it takes
#in areas described in IEEE Std 1003.1-2001 as implementation-defined or
#unspecified, or where IEEE Std 1003.1-2001 indicates that implementations
#may vary.

How should we interpret this?


David