3 ms·
> If you read /proc, you must "read" each file with one unbuffered kernel read to be free of race conditions AFAIK, as that StackOverflow page also says, that’
by Someone 3y ago
> If you read /proc, you must "read" each file with one unbuffered kernel read to be free of race conditions
AFAIK, as that StackOverflow page also says, that’s not guaranteed to be possible. https://man7.org/linux/man-pages/man2/read.2.html https://man7.org/linux/man-pages/man2/read.2.html:
“RETURN VALUE
On success, the number of bytes read is returned (zero indicates end of file), and the file position is advanced by this number.
It is not an error if this number is smaller than the number of bytes requested; this may happen for example because fewer bytes are actually available right now (maybe because we were close to end-of-file, or because we are reading from a pipe, or from a terminal), or because read() was interrupted by a signal”
I think you can avoid the “because read() was interrupted by a signal” part by not installing signal handlers, but even if that’s an option for you, that list isn’t exhaustive.
Your best bet is to pass the maximum supported number for count to the call (SSIZE_MAX in POSIX, 0x7ffff000 on Linux, and hope that the call returns all bytes.
Luckily, I think that will be fine most of the time, but that doesn’t mean /proc is a good idea.
- dezgeg 3y agoIn practice signals don't seem to be a problem for (most?) proc files as the seq_file infrastructure doesn't bother to check for pending signals and terminate the read if so. Naturally, only source reading will answer whether the proc file you're interested in is vulnerable to this or not.
- Someone 3y ago> Naturally, only source reading will answer whether the proc file you're interested in is vulnerable to this or not. At the moment. To be sure, you also have to keep track of changes to that source code to look for regressions, and have a mechanism to update all your deployed code if there is a regression there. It could require multiple attempts at reading, and still doesn’t ensure progress, but I think /proc would be a lot more reliable if file contents included a good checksum.
- deleted 3y ago[deleted]
- __david__ 3y agoYour best bet is to pass the maximum supported number for count to the call (SSIZE_MAX in POSIX, 0x7ffff000 on Linux, and hope that the call returns all bytes. And then just hope your read buffer doesn’t overrun? Because 2GB is a lot of buffer to allocate for a read…
- o11c 3y agoThere are several special file types where the return value of `read` is guaranteed more than the general case. For example, `timerfd_create`'s returned FD guarantees that `read` will always return exactly 8.