File system capabilities break leak sanitizer

[wintersteiger]

Not sure whether this is an actual bug or just an unexpected consequence, but it would be good to get an experts opinion:

When I use setcap to give my binary permission to bind to privileged ports, the leak sanitizer throws a fatal error.

For example:

$ cat setcapleakchk.cpp
int main() { return 1; }

$ clang++-15 -o setcapleakchk setcapleakchk.cpp -fsanitize=leak
$ sudo setcap CAP_NET_BIND_SERVICE=+eip setcapleakchk
$ ./setcapleakchk
==2203001==LeakSanitizer has encountered a fatal error.
==2203001==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1
==2203001==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)

The suggested environment variable settings make no difference and it works as intended without the setcap command. Tested with clang 10 and 15:

$ clang++-10 --version
clang version 10.0.0-4ubuntu1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

$ clang++-15 --version
Ubuntu clang version 15.0.0-++20220530092253+14cc4674bf5a-1~exp1~20220530092306.267
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

[johnthacker]

This is this issue.

I assume you have proc/sys/fs/suid_dumpable set to 2, which is "dumpable, but only by root (and creates core files owned by root.)". Anything with capabilities or setuid resets its dumpable flag from 1 to the value in suid_dumpable. The check in StopTheWorld changes the value temporarily if it's 0 to 1 and back, but does nothing if it's 2.

However, an unprivileged program can't change the value back to 2, because there's was a CVE with root exploit being able to do so. In order to perform LSan, would have to change it to 1 and then presumably to 0.

Setting suid_dumpable to 2 is less restrictive than 0, but it breaks LSan in this way.