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!

Ja das stimmt,
da habe ich mit sysopen wohl etwas falsch verstanden. Es kann doch nicht flock()en.

Quote

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.

Nein, dass stimmt nicht.
Wenn du O_EXCL zusammen mit O_CREAT benutzt, dann wird eine Datei nur dann erzeugt, wenn sie noch nicht existiert. Und das bezieht sich auch auf Hard Links, nicht nur auf Symlinks. Ich habe das selber ausprobiert, und es kam bei einen Hardlink eine Fehlermeldung.

Anhand dessen würde ich schon sagen das ein sysopen sicherer ist als ein reines open. Den mit open ist man nicht in der Lage so fein zu sagen, was man wirklich möchte. Ein (open, ">") legt eine neue Datei ein, wenn Sie existiert wird sie überschreiben. Sowas kann man mit sysopen regeln, dass das letzte eben nicht passiert. (Allerdings klappt sowas laut beschreibung nicht mit Netzlaufwerken wie z.B. NFS). Allerdings stimmt es das die Race Condition nur dann existiert wenn man ein Dateitest gefolgt von einem open macht. Mit flock() hat das doch nichts zu tun.

Quote

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 trodem weg.

Die Datei copy.txt war ein Hardlink auf eine andere Datei, es wurde bei mir erfolgreich "Datei existiert bereits: File exists" ausgegeben.

Quote

Deswegen aber hier hartnäckig zu behaupten "open ist unsicher, sysopen ist sicherer", halte ich für Humbug.

Das es sicherer ist würde ich immer noch behaupten. Allerdings stimmt es das es nichts mehr mit der Verwendung von flock() zu tun hat.

Allerdings beschränkt sich der Sicherheitsvorteil nur darin, wenn man z.B. folgendes haben möchte:
- Datei zum Schreiben öffnen, neue Datei erzeugen, Datei darf noch nicht existieren
- Datei öffen zum Anhängen, Datei muss existieren
- Datei öffnen für Aktualisierungen, Datei darf noch nicht existieren
- Datei öffnen für Aktualisierungen, Datei ggf. erzeugen

Mit "Aktualisierung" ist gemeint gleichzeitiges Lesen/Schreiben.

Wenn man sowas nicht benötigt, hat sysopen sicherlich auch keine Sicherheitsvorteile.\n\n

<!--EDIT|sid burn|1145803598-->

Du hast recht. Das mit dem O_CREAT|O_EXCL hatte ich in der Manpage falsch verstanden, es bricht grundsätzlich ab, wenn die Datei schon existiert oder ein Symlink ist.

Wie du schon sagst, hat man bei sysopen() die feinere Auswahl, vor allem, wenn man existierende Dateien explizit nicht überschreiben möchte. Das kann man mit open() nicht atomar lösen.

Wenn man aber die Funktion "neu anlegen oder überschreiben" haben möchte, wie sie ein "open FOO, '>', $dateiname" oder "open FOO, '>>', $dateiname" erledigen, dann ist man auch mit sysopen() nicht vor Symlink-Angriffen sicher, denn ein Test auf einen Symlink müsste sowohl bei sysopen() als auch bei open() vorher erfolgen, wäre somit wieder nicht atomar.

Ansonsten ist der letzte Punkt in deiner Liste vielleicht die häufigste Anwendung, die man nicht gut mit open() lösen kann: Lesen, schreiben und evtl. anlegen (O_RDWR|O_CREAT) in Kombination mit Locking. Das findet man dann auch in perldoc -q "get locking".

[quote=Dubu,22.04.2006, 22:52][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![/quote]
Doch, es geht, wenn es das darunterliegende Betriebssystem kann. Gottes eigenes Betriebssystem kennt z.B. die Optionen

beim open-Systemcall. Ich nehme an, dass diese auch bei sysopen zur Verfügung stehen.

Okay, mein Linux kann's nicht (laut open(2), libc6 2.3.6).

Bei FreeBSD 4.9 kann man es auch tatsächlich benutzen:

und ein anschließendes lsof zeigt die FD-Flags 4uW (W für Write lock) an.