URL:
https://github.com/SSSD/sssd/pull/5370
Title: #5370: nss: Use posix_fallocate() to alloc memcache file
simo5 commented:
"""
> I think you are correct that we cannot rely on the file
appearing zero filled following a call to `posix_fallocate()`. There could then be a small
race where a client does not treat the cache file as
[
un-initialised](https://github.com/SSSD/sssd/blob/b913ddbd5aec9ea87ddbf10....
Yes, this is what I was thinking about.
On the other hand: even taking into account `fallocate` (used under the hood on Linux
systems) doesn't initialize allocated FS blocks, what else could `read` return if not
zeros?
I mean FS "knows" blocks aren't initiated and thus will not read garbage
left on the disk (would be a security threat).
Would be good to find a confirmation :) I wouldn't like to complicate things without
a reason.
Certainly you won't get random disk sectors out of it, and in case of mmap new memory
pages are always zeroed before handling them to the user process, so you can bet that all
this space is intialized to zero.
(If you have doubts write a simple test program to check it :-)
> On the concern over the note in the glibc docs, the most obvious
way I can see this manifesting is when working with copy-on-write cloned files, which we
aren't doing here (however I guess there are other scenarios). It's also not clear
if this note relates only to the emulated behaviour of `posix_fallocate()`. I think
it's fair to say that the general behaviour of `posix_fallocate()` is closer to what
we need than `ftruncate()`, even with this caveat.
Agree.
+1
"""
See the full comment at
https://github.com/SSSD/sssd/pull/5370#issuecomment-709481365