Race between file reader and writer in FileSessionCredentialsProvider

[leventov]

A race is possible between the file updater and the Druid process reading the file. It could be enforced only with mandatory file locking, but file locking is advisory by default in Linux.

If Druid targets only Linux (is it?) probably some Linux-specific code could be added to configure mandatory file locking for sessionCredentialsFile.

[gianm]

Are you talking about Druid possibly reading partially-written content from a file? If so, then in general, the right way to update a file on a POSIX system that might have concurrent readers is to write a tmp file on the same filesystem, and then rename the new file over the old one. If you need the file's data to be durable after a system crash, you should fsync the file too, and the directory entry for the parent directory. The file updater external to Druid should be doing all of that, and if it does, then Druid can get a consistent read of the file.

Mandatory locking is supported in Linux but frowned upon (https://lwn.net/Articles/667210/).

See FileUtils.writeAtomically for an example of code in Druid that gets it (mostly) right. Although it's not fsyncing the containing directory entry, and it should be. That should be fixed.

[gianm]

#6677 adds fsyncing of the directory entry to FileUtils.writeAtomically.

[leventov]

Is update of sessionCredentialsFile outside of the control of Druid? Then probably we couldn't do much, except maybe add note in documentation (for Druid operators) that the file should be updated in the atomic manner as you described.

[gianm]

It looks to me like the intention is that the session credentials file would be updated by some external, not-Druid process.

[github-actions]

This issue has been marked as stale due to 280 days of inactivity.
It will be closed in 4 weeks if no further activity occurs. If this issue is still
relevant, please simply write any comment. Even if closed, you can still revive the
issue at any time or discuss it on the dev@druid.apache.org list.
Thank you for your contributions.