|
|
| P is for Practical | |
| PerlMonks |
Re (tilly) 3: is I/O checking worth it?by tilly (Archbishop) |
| on Jan 14, 2001 at 18:31 UTC ( [id://51795]=note: print w/replies, xml ) | Need Help?? |
This is an archived low-energy page for bots and other anonmyous visitors. Please sign up if you are a human and want to interact.
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.
In Section
Meditations
|
|
||||||||||||||||||||||||