@trasz Do we have a good regression suite I can try? How difficult / big is running something like LTP?

The reason we handle CLONE_FS by setting RFFDG is because a process' cwd (and chroot dir and umask) is stored in the fd table. I'm not sure how we could implement CLONE_FS properly, it'd require some modification to the core kernel.

With this diff CLONE_FS is effectively ignored. I don't have any objection to that, but I'd be surprised if it doesn't break something.

In D27016#602731, @markj wrote:

The reason we handle CLONE_FS by setting RFFDG is because a process' cwd (and chroot dir and umask) is stored in the fd table.

Yeah, I got that.

I'm not sure how we could implement CLONE_FS properly, it'd require some modification to the core kernel.

Yes, we’d have to break those settings out like Linux presumably does.

With this diff CLONE_FS is effectively ignored. I don't have any objection to that, but I'd be surprised if it doesn't break something.

Yeah, that is effectively the change, and I’m also concerned about what it might break. I think expecting the FS semantics would be extremely strange, but I haven’t investigated why Chrome does it. Certainly there are other clone() calls in chrome that do not include that flag. I also wonder if LTP covers this flag.

If the original comment is to be believed, maybe many FS users also pass FILES, and wouldn’t be broken here.

Datapoint: glibc does not appear to use CLONE_FS anywhere internally (or rather, only once, in tandem with CLONE_FILES, for creating threads): https://github.com/bminor/glibc/search?q=CLONE_FS

Chromium uses it (without CLONE_FILES) in a few places. Ignore seccomp and nacl for now. https://github.com/chromium/chromium/search?q=CLONE_FS The uses in tandem with SIGCHLD (0x11 on Linux) matches the 0x211 I observed.

One use is this mechanism, which, wow: https://github.com/chromium/chromium/blob/ba5cf7b3d18065b934e9a55e2380450f28ad585a/sandbox/linux/services/credentials.cc#L48-L108

Chrome spawns a child process to chroot both child and parent into a pseudo-directory specific to the child process, which then exits. So, uh, wow. CLONE_FS is definitely intended there. On the other hand, VFORK also means it is safe (sort of) to skip RFFDG for CLONE_FS. So I think we could handle this case safely with something like:

/* Do not create independent fd table copy if CLONE_FILES is set, or if (CLONE_FS | CLONE_VFORK) is set. */
if ((args->flags & LINUX_CLONE_FILES) == 0 &&
    (args->flags & (LINUX_CLONE_FS | LINUX_CLONE_VFORK)) != (LINUX_CLONE_FS | LINUX_CLONE_VFORK))
        ff |= RFFDG;

which is a bit ugly, but does not require implementing Linux's CLONE_FS semantics.

This use is much the same, except it requires the parent and child to run contemporaneously, because the child does not chroot until it receives a write on the shared socketpair: https://github.com/chromium/chromium/blob/e65f318c604d2159e65edda605863b98d36e2073/sandbox/linux/suid/sandbox.c#L72-L162 So our vfork hack would not work here, and the parent would remain un-chrooted. The API which actually uses this socketpair to chroot itself is in another file: https://github.com/chromium/chromium/blob/2ca8c5037021c9d2ecc00b787d58a31ed8fc8bcb/sandbox/linux/suid/client/setuid_sandbox_client.cc#L95-L132 I think Chrome might work anyway without correct sandboxing, but obviously it is not ideal. Anyway, Chrome can be run with --no-sandbox, which appears to avoid execution of this path (and possibly the earlier one as well).

All other uses of CLONE_FS in chrome appear to be either unittests or in tandem with CLONE_FILES.

That second use dates to, effectively, 2013, where it was added without any non-test consumers: https://github.com/chromium/chromium/blob/486efc8695c31bd2084db07bd47f104451553cc6/sandbox/linux/services/credentials.cc#L90-L134 At the time, it spawned a normal thread rather than using clone() directly, and subsequently unshare()'d CLONE_FILES, giving us essentially the same problem: Chrome wants to chroot from a subprocess without shared fds, and then have the subprocess die.