URL:
https://github.com/SSSD/sssd/pull/5370
Title: #5370: nss: Use posix_fallocate() to alloc memcache file
alexey-tikhonov 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.
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.
"""
See the full comment at
https://github.com/SSSD/sssd/pull/5370#issuecomment-709471668