in reply to Re^3: opening files: link checking and race conditions
in thread opening files: link checking and race conditions

Thank you. The problem with my approach is now clear -- and in the timing scenario you laid out, the script will have no problem writing to that file handle after the second symlink check passes. Once the "open" has succeeded, FH is pointing directly to the actual target file, and deletion of the symlink has no impact on the ability to write successfully to the file.

Well then, here's one last try:

unless ( -l "foo" ) { # we get here fine #*now* the link is created open( FH, ">>foo" ) or die "foo: $!"; #and now it's removed again } die "Link attack detected" if ( -l "foo" or ! -e _ ); # we have checked for both existence and "type == symlink" on the same + stat call, # so either it's a link, or it's non-existent, or it's safe to write o +utput

Replies are listed 'Best First'.
Re^5: opening files: link checking and race conditions
by Eimi Metamorphoumai (Deacon) on Aug 03, 2005 at 17:57 UTC
    # we have checked for both existence and "type == symlink" on the same + stat call, # so either it's a link, or it's non-existent, or it's safe to write o +utput
    Or you opened the symlink, someone replaced it with a regular file, and you statted that. Again, you can make it pretty hard to exploit, but you can't get rid of it entirely without either doing it atomically at the time of the open (O_NOFOLLOW) or can check on the filehandle you actually have open (and not what that name points to now).

    What might work (but I'm not at all certain) would be to stat the filehandle you have open, stat the file you thought you opened, and confirm that they have the same inode and that it isn't a symlink.