Re: opening files: link checking and race conditions

I hope I am not being dense, but I can't yet see why you can't check for linkness on the file using it's spec but after opening.

my $lflag;
open my $fh, ">>foo" or ErrorHandler( $?, $! );
$lflag = ( -l 'foo' );
unless( $lflag } {
    # process file
}
close $fh; # it was opened for append but append only occurred for non
+-link case
[download]

One world, one people

Comment on Re: opening files: link checking and race conditions Download Code

Replies are listed 'Best First'.
Re^2: opening files: link checking and race conditions by Joost (Canon) on Aug 03, 2005 at 12:48 UTC
Erm, that just reverses the race-condition. Now all an attacker needs to do is to replace the link with an actual file after it's opened. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^3: opening files: link checking and race conditions by anonymized user 468275 (Curate) on Aug 03, 2005 at 13:15 UTC
okay but if that is a problem too, doesn't this fix both? `my $lflag = ( -l 'foo' ); # check before opening $lflag or open my $fh, ">>foo" or ErrorHandler( $?, $! ); $lflag = ( -l 'foo' ); # and again after opening unless( $lflag } { # process file } $lflag or close $fh;` [download] One world, one people	[reply] [d/l]
Re^4: opening files: link checking and race conditions by Joost (Canon) on Aug 03, 2005 at 13:32 UTC
No, the whole point is that you can't guarantee that the thing the filename "foo" points to doesn't change between operations. You're only making it harder, not impossible, to mess with foo. update see Re: opening files: link checking and race conditions for code that can cause your method to fail, and Re^2: opening files: link checking and race conditions for the best solution (even if it's not 100% portable) "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^4: opening files: link checking and race conditions by danderson (Beadle) on Aug 03, 2005 at 22:55 UTC
Google "atomicity" and "race case" for more information, but here's a brief way how that would die: (P1 is process 1, P2 is process 2, they're not actually in the same program, but the commands from each are interleaved here since that can happen in reality) `P1: my $lflag = ( -l 'foo' ); # seems good P2: makes foo a link - uh oh! P1: $lflag or open my $fh, ">>foo"; # does it fine, since $lflag was s +et before P2: remove that link, lickity-split! P1: $lflag = ( -l 'foo' ); # whups, everything seems ok...` [download] Make sense? Dave_the_m's code will exactly perform the actions for P2, btw. (Eimi's earlier explanation did exactly what your code does, too - look it over, the -l check happens before and after.)	[reply] [d/l]