Re: Re (tilly) 1: is I/O checking worth it?

[Beatnik]

I usually do alot of checking on more critical file I/O, instead of blindly opening, and I once so often even do a forced check on file permissions (which ofcourse will break the script on platforms that don't support it).
Locking will only work on processes that understand the concept. If applications don't obey file locking, they can do whatever they want with the files. Perl, ofcourse, obeys the locking.
Not all OSs have flock implemented, good example: Windows (not that I use it). flock will actually break your script if it's run on a platform that doesn't support it.
What about the file versus dir check? A file can be opened, a dir can't (in a file meaning). Will -d suffice enough? =)

[tilly]

Actually locks on Unix are only advisary, and while Perl scripts may obey them, it depends on the script writer properly calling flock.

As for the rest, generally it is a far sounder strategy to open in a non-destructive manner, then test. Testing first opens up race conditions.

Beyond that putting in a ton of paranoid checks tends to create unmanageable messes. The harder you make security, the less likely it is to happen. Make it easy to be secure (eg through a small number of functions like I wrote above) and think about how it fits in your overall policy. (I might work as a non-privileged user in directory structures whose permissions are locked down to just that user, then leave it at that. If I want to put a symlink in there, that is probably OK.)

In general make sure that things are sane, you have programmed in a way where unexpected inputs cannot be misunderstood, and make it simple to maintain that. But if (and without seeing what you do I have no idea whether this applies in your case) you set up a complex scheme that is supposed to be followed, you have set yourself up for failure. Complex schemes tend to erode security.