On Mon, 12 Jun 2000, Andries Brouwer wrote:
> It is the normal path resolution behaviour of symlinks.
> The result of path resolution is a directory and a name
> to be used (possibly created) in this directory.
Yes. Now compare that with behaviour of mkdir(), mknod(), bind() on
AF_UNIX sockets or any other operation that creates objects. Compare also
with behaviour of unlink(), rmdir() and rename().
> utime( ). Interfaces that historically do not follow symbolic links
> include chown( ), lstat( ), readlink( ), rename( ), remove( ), rmdir(),
> and unlink( ). IEEE Std. 1003.1-200x deviates from historical
> practice only in the case of chown( ).
Lovely. IOW, draft sucks badly for mkdir() too - AFAICS with security
consequences. And makes 4.4BSD, Solaris and Linux non-compliant in
bargain. mkdir() on a dangling symlinks does not follow links on any of
these systems. Let's see... Yep, mknod() also doesn't follow them. Care
to reconsider the piece above? Or should this "include" be read as
"include, but are not limited to"?
Please, fix the draft. Either clarify this "include" or stop making
factually incorrect claims. By the way, bind() on AF_UNIX sockets should
not follow links too - look through BUGTRAQ archives for gory details.
> no trailing slash. 3. The function is required to act on the symbolic
> link itself, or certain arguments direct that the function act on the
> symbolic link itself. In all other cases, the system shall prefix the
> remaining path name, if any, with the contents of the symbolic
> link. If the combined length exceeds {PATH_MAX}, and the
Which is wrong in cases like Linux procfs.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:24 EST