Re: OPEN, STATUS='NEW' of a symbolic link to a non-existing file.

[Janne Blomqvist <blomqvist dot janne at gmail dot com>]

Toon Moene wrote:
> Steve Kargl wrote:
>
> > Looks like inquire has a bug.
> >
> > As you know, the unix philosophy is that everything is a file.
> > symlinks (and directories and devices and ...) may by special
> > files, but nonetheless they are files.
>
> Well, we can agree to disagree then.
>
> To me a symlink is an alias (another name) for a file.
>
> The file either exists or it doesn't.  The fact that the existence of 
> the symlink leads to a failure in OPEN(..., STATUS='NEW',...) is just a 
> consequence of us using open(..., O_CREAT | O_EXCL, ...).
>
> The documentation of open is quite explicit: links are not followed when 
> deciding on O_EXCL.

Yes, and for good reason. Symlink attacks, temp file races and such have 
been part and parcel of unix security history. Luckily it's possible to 
avoid them by using, among other techniques, O_CREAT|O_EXCL 
appropriately. While Fortran typically isn't used for creating security 
sensitive applications, we shouldn't at least go out of our way to make 
writing such applications with gfortran harder than it already is.

As the manpage mentions, O_EXCL doesn't work on NFS, and the fix it to 
use a separate lock file and check the link count; however, lock files 
sound even harder to justify from a "consistency with other compilers" 
and user expectancy standpoint. So I think that at the moment we have to 
contend with a "works atomically on a local filesystem" best-effort. As 
a curiosity, NFS 4.1 finally allows O_EXCL to work properly.

I think STATUS='new' matches pretty well with the semantics of 
O_CREAT|O_EXCL; i.e. create a new file and error out if that is not 
possible. The reason why symlinks exists from the perspective of O_EXCL 
is to prevent symlink attacks. OTOH one could argue that a dangling 
symlink is different, but I think it's more important to preserve the 
atomicity of O_CREAT|O_EXCL and thus to behave like POSIX and consider a 
dangling symlink as an error that the user must fix before opening the 
file with STATUS='new'.

I suppose one could make a case for replacing the use of stat() in 
unix.c:file_exists() with lstat(), but that would again break the case 
when testing for the existence with inquire, then opening with 
STATUS='old', in case of a dangling symlink. So no matter which way you 
look at it, dangling symlinks are broken in some way. With that in mind, 
I'd vote for keeping the current behavior.

As an aside, testing for file existence with inquire is race-prone, and 
the proper way really is to try to open it with IOSTAT or IOMSG.

> I think we're better off following the crowd here (although I've only 
> tested xlf (IBM) and ifort (Intel)).

As Nick explained, whatever we do, some other widely used compilers are 
going to do it differently.

--
Janne Blomqvist