(If you `close(STDERR_FILENO);` then the STDERR_FILENO descriptor can be reused for other files afterward.) Takeaway #2: libs will assume you follow the advice from Takeaway #1 or don't care. Thus we must assume all libs write to STDERR_FILENO. E.g. https://bugs.chromium.org/p/boringssl/issues/detail?id=247 ….
-
-
Show this thread
-
Takeaway #3: Sandboxing frameworks need to deal with this issue in some way. They can't blindly block syscalls like `dup2()` or completely block `/dev/null` unless they've otherwise already ensured that STDERR_FILENO is always a valid file descriptor that is safe to write to.
Show this thread -
Takeaway #4: If you're developing an operating system with POSIX-y stdin/stdout/stderr stuff, don't ever implicitly reuse STD*_FILENO file descriptors after those file descriptors have been closed.
Show this thread
End of conversation
New conversation -
-
-
If piles of people object to this, I'll change BoringSSL. But I've always operated under assumption #2 here. I think it's just A Thing with POSIX systems.
-
I think we just have to assume, as library users, that this is what libraries will do. I think it glibc wasn't already doing it then it would make more sense to avoid doing it. It seems much safer than `fwrite(stderr)`, at least.
End of conversation
New conversation -
-
-
I seem to remember something about glibc even opening /dev/null as fd 0,1,2 if they aren't open yet at startup of a suid process as a default hardening measure, but can't find any reference to it easily
-
For suid programs this is a very real vuln class, and it was also useful for exploiting kernel issues with special file handles that had access checks at read/write time instead of at open time.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.