Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re^3: opening files: link checking and race conditions

by Eimi Metamorphoumai (Deacon)
on Aug 03, 2005 at 15:15 UTC ( [id://480512]=note: print w/replies, xml ) Need Help??


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

Because you're still vulnerable to the race condition, it's just very timing dependent. Here's how the timeline falls out. At first, the file doesn't exist.
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" ); #too late, the link is gone already, so we didn't die.
Now, it's really, really hard to get the timing to work perfectly for that, but that doesn't mean that it won't happen sometimes. So if you start a program creating and removing the link very quickly, and at the same time run the other program again and again, sooner or later you're going to get unlucky.

Replies are listed 'Best First'.
Re^4: opening files: link checking and race conditions
by graff (Chancellor) on Aug 03, 2005 at 17:22 UTC
    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
      # 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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://480512]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others taking refuge in the Monastery: (5)
As of 2024-03-28 13:31 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found