Wie unique ist boost::filesystem::unique_path?



  • Hallo,

    so wie ich die Doku von boost::filesystem::unique_path verstehe, wird durch diese Funktion einfach ein zufälliger Name erstellt und man geht davon aus dass das schon passen wird.

    Trotzdem besteht ja noch die Möglichkeit einer Kollision, die Funktion ist also nicht 100% sicher, oder?

    Wieso wird nicht einfach geprüft ob der Pfad schon existiert und falls ja solange weiter zufällige Pfade erzeugt bis einer dabei ist der wirklcih unique ist? Weil so verdient die Funktion ja ihren Namen nicht wirklich, oder sehe ich da was falsch?



  • Wieso wird nicht einfach geprüft ob der Pfad schon existiert und falls ja solange weiter zufällige Pfade erzeugt bis einer dabei ist der wirklcih unique ist? Weil so verdient die Funktion ja ihren Namen nicht wirklich, oder sehe ich da was falsch?

    1. Das ist zeitlich sehr aufwändig und daher nicht immer gewollt.

    2. Da andere Programme jederzeit ein Verzeichnis erstellen können, kann man ohnehin nicht sicher sein ob der Pfand einzigartig ist. Erst wenn das Verzeichnis erstellt ist, weiß mans.



  • Die Wahrscheinlichkeit einer Kolission mit 1 zu 2^64-(num of files) ist relativ klein.

    happystudent schrieb:

    Wieso wird nicht einfach geprüft ob der Pfad schon existiert und falls ja solange weiter zufällige Pfade erzeugt bis einer dabei ist der wirklcih unique ist? Weil so verdient die Funktion ja ihren Namen nicht wirklich, oder sehe ich da was falsch?

    Ja, unique_file ist ein Security-Problem. Sie mancht so ziemlich das gleiche wie tmpnam und das ist unsicher:

    <a href= schrieb:

    tmpnam ">Warning: Between the time the pathname is constructed and the file is created another process might have created a file with the same name using tmpnam, leading to a possible security hole. The implementation generates names which can hardly be predicted, but when opening the file you should use the O_EXCL flag. Using tmpfile or mkstemp is a safe way to avoid this problem.

    Es kann passieren (und das ist nicht mehr 2^-64), dass ein Angreifer den Rückgabewert von unique_path erhält bevor du die Datei öffnen kannst. Dann erstellt er einen Symlink auf irgendwo und du hast ein Problem. Lösung ist O_EXCL, das stellt sicher, dass du die Datei auch wirklich erstellst.

    Meines Wissens nach kannst du unter Boost.Filesystem aber kein O_EXCL -Flag angeben. Also hast du ein Problem.

    Deine Lösung hat diese Race-Condition übrigens auch noch, du kannst überprüfen, ob die Datei existiert und sie danach öffnen, aber in der kurzen Zeit dazwischen könnte sie ja erstellt worden sein: It's easier to ask forgiveness than it is to get permission.

    TL;DR: unique_path ist unsicher.



  • coder777 schrieb:

    1. Das ist zeitlich sehr aufwändig und daher nicht immer gewollt.

    Schon, aber dann hätte man das ja besser random_path nennen können. Und noch eine zweite Funktion anbieten die das beschriebene macht und die dann unique_path nennen.

    schmecurity schrieb:

    Die Wahrscheinlichkeit einer Kolission mit 1 zu 2^64-(num of files) ist relativ klein.

    Das schon, aber ich frag mich halt ob das bei sicherheitskritischer Software nicht trotzdem zu unsicher ist...

    coder777 schrieb:

    2. Da andere Programme jederzeit ein Verzeichnis erstellen können, kann man ohnehin nicht sicher sein ob der Pfand einzigartig ist. Erst wenn das Verzeichnis erstellt ist, weiß mans.

    schmecurity schrieb:

    Ja, unique_file ist ein Security-Problem. Sie mancht so ziemlich das gleiche wie tmpnam und das ist unsicher:

    Es kann passieren (und das ist nicht mehr 2^-64), dass ein Angreifer den Rückgabewert von unique_path erhält bevor du die Datei öffnen kannst. Dann erstellt er einen Symlink auf irgendwo und du hast ein Problem. Lösung ist O_EXCL, das stellt sicher, dass du die Datei auch wirklich erstellst.

    Meines Wissens nach kannst du unter Boost.Filesystem aber kein O_EXCL-Flag angeben. Also hast du ein Problem.

    Ok, alles klar... das ist natürlich blöd wieso bietet boost sowas wichtiges nicht an? 😞



  • schmecurity schrieb:

    TL;DR: unique_path ist unsicher.

    Warum denn? Ich dachte jetzt wäre O_EXCL die Lösung.



  • TyRoXx schrieb:

    schmecurity schrieb:

    TL;DR: unique_path ist unsicher.

    Warum denn? Ich dachte jetzt wäre O_EXCL die Lösung.

    Wie machst du das mit Boost.Filesystem?

    [Disclaimer: unique_path ist natürlich nicht per se unsicher, aber im Kontext von Boost.Filesystem schon]


Log in to reply