On Sun, 11 Jun 2000, Alan Cox wrote:
> > > Yes. The new POSIX draft standard says
> > > "In general the open() function follows the symbolic link
> > > if path names a symbolic link."
> > > (The exception is the case O_CREAT|O_EXCL.)
> >
> > Excuse me, but I'll take difference from POSIX over a bunch of very real
> > races, thank you very much. Again, feel free to propose race-free
> > implementation if you want that thing back. Until then O_CREAT without
> > O_EXCL will return -ENOENT on broken symlinks. Userland should not rely
> > on objects' creation/removal following symlinks. Period.
>
> POSIX says otherwise. Period ;)
>
> The case we are about is O_EXCL. That the magic security concious etc
> case. If a symlink is moved while we are opening to create then who cares ?
> BSD added an option to not follow links which cleaned up even those cases
> for the worried and paranoid (as wlel as being handy for removing stat
> calls in httpd)
>
> If posix said O_CREAT|O_EXCL had to follow I would be concerned. O_CREAT
> following is fine.
Except that we don't know which directory should be locked. Alan,
original implementation (in BSD) followed links on every operation.
Everyone gradually had to take that away on all creation/removal cases
except that one. Notice that O_EXCL is different: plain O_CREAT applied to
a normal symlink will happily open the targt, with O_EXCL it will return
-EEXIST. IOW, in case of O_EXCL we are asking for a different behaviour
which happens to prohibit following broken links for a different reason.
It doesn't remove the reasons for doing the same without O_EXCL.
In other words, in that case POSIX draft is broken and we would be
better off fixing that bug instead of casting it in stone. Behaviour in
question is inconsistent with every other case when links are
created/removed/renamed.
-
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:23 EST