linux-kernel - O_CLOFORK use case

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+jjjYT6_ZZP5Ucqxvtmcd3d18vAC1LRtruiXojFVaxpJ-HhLA@mail.gmail.com>
Date:   Mon, 3 Jun 2019 08:24:44 -0700
From:   Joshua Hudson <joshudson@...il.com>
To:     linux-kernel <linux-kernel@...r.kernel.org>
Subject: O_CLOFORK use case

I ran headlong into the use case for O_CLOFORK and got into a locking
debate over it.

The actual use case involves squashing a thread race between two
threads. If a file is opened for write in one thread with O_CLOEXEC
while another thread calls fork(), a race condition can happen where
the thread that closes the handle misses the out of disk error because
the child process closed the handle last inside execve().

The decades old idiom for replacing config files isn't safe in
multi-threaded code. Yipe.

    int h = open(".configfile~", O_WRONY | O_EXCL | O_CLOEXEC, 0666);
    if (h < 0) { perror(".configfile"); return 1; }
    ssize_t delta = 0;
    while ((delta = write(h, newconfigdata, newconfiglen)) > 0) {
        newconfigdata += delta;
        newconfiglen -= delta;
    }
    if (delta < 0) { perror(".configfile"); return 1; }
    if (close(h)) { perror(".configfile"); return 1; }
    rename(".configfile~", ".configfile");

To fix it, we have to put locks around close() and fork()/vfork(). Ugh.