[Dovecot] I stream read - stale NFS file handle (reboot of server)

[Edgar Fuß]

> To fix (well work around) a security issue, for about 10+ years now,
> when a NFS server reboots, it generates a new random handle for the
> NFS Share. (sever may generate a new random handle per mount
> request)
I don't concur.

NFS is stateless and designed to survive server reboots (why would you have stad otherwise?). What you do is inode randomization on the file system backing the NFS export.

You get those stale handles when someone on the client has a file on the mount open and some other way the file gets deleted (by another client or right on the server). Since NFS is stateless, the server knows nothing about the file being open. If the file was open on a local file system, the kernel wouldn't actually free the inode because there's still a reference (albeit with no directory entry) on it. But NFS lacks this reference. So clients can work around this by converting unlinks to renames to .nfsXXXX names and sending an unlink to the server only on the last local unlink. Of course, this works only with one client.

Just to make sure I rememberer all this correctly, I just confirmed with The BooK: See the fourth paragraph of "The NFS Protocol" in Section 9.2 of McKusick/Bostic/Karels/Quarterman (in my edition it's on page 317)