[quote=sid burn,22.04.2006, 21:23]Mit sysopen würde das nicht passieren. Da man gleichzeitig z.B. auf symlink, datei öffnen, und flocken kann.[/quote]
Ich habe das Heft auch nicht zur Hand, aber so, wie du es beschreibst, bestand die Lücke offensichtlich zwischen dem Test auf Symlink und dem open().  Das hat absolut nix mit flock() zu tun. Und nein, sysopen() kann nicht gleichzeitig flock()en!

Wie pq schon sagte, sind Locks ohnehin nur advisory: Wenn ein Programm kein flock() benutzt, dann hat das andere Programm Pech gehabt. Ein flock() kann daher nie vor einem böswilligen Programm schützen.

Aber sysopen() kennt die Optionen O_EXCL und O_CREAT, die zusammen verhindern, dass eine Datei überschrieben wird, wenn sie ein Symlink ist (siehe perldoc -f sysopen). Dieser Kombination wurde wohl in dem Beispiel zur Absicherung vor Symlink-Attacken benutzt.

(Das hilft aber auch nur gegen Symlink-Attacken. Was ist wohl, wenn ich einen Hardlink auf die anzugreifende Datei anlege? Das kann sysopen() nicht erkennen, und meine /boot/vmlinuz ist trotzdem weg. Wenn der Admin /boot auf eine separate Partition legt, nehme ich eben die /etc/passwd oder eine andere kritische Datei.)

Du hast Recht, dass Perls open() existiert, um dem Benutzer eine einfache Möglichkeit zum Lesen und Schreiben von Dateien zu geben. Es ist ja auch einfacher, "open FILE, '>', $dateiname" zu schreiben, als sich die passenden Optionen für sysopen() zu merken. Auch kann man mit open() einfach Umleitungen und Pipes realisieren, wie man es von der Shell kennt (naja, sofern man überhaupt eine Shell kennt).

Deswegen aber hier hartnäckig zu behaupten "open ist unsicher, sysopen ist sicherer", halte ich für Humbug. Und dass ich mir durch ein sysopen() das flock() dahinter sparen könne, ist schlicht falsch.