https://bugs.openldap.org/show_bug.cgi?id=10562
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Howard Chu hyc@openldap.org --- There's no bug here, the behavior is already documented.
MDB_NOLOCK is not safe on a writable DB, but that's already documented as well.
"Open the environment in read-only mode. No write operations will be allowed. LMDB will still modify the lock file - except on read-only filesystems, where LMDB does not use locks."
Therefore, on writeable filesystems, MDB_RDONLY will still cause writes to a lockfile.
Yes, that is precisely what the documentation says.
Because the filesystem is writable, the lock file is opened O_RDWR|O_CREAT. For an unprivileged reader this returns EACCES. mdb_env_setup_locks() only tests for EROFS, so the open fails with EACCES (13).
Yes, EROFS means no changes are possible so it's safe to open the environment. EACCES means the filesystem is writable, so it's unsafe to proceed, which is why the open is failed.
A minimal change to LMDB code would be to return something other than EACCES in this case so that the user is informed about what is happening, and can then decide whether MDB_NOLOCK is safe, or something else.
That's not a decision an arbitrary user can make. Without coordination with any other software that may be using the DB, it is entirely unsafe.
There is no generic fix for this. The solution systems like Postfix uses is to impose their own flocks, so they use MDB_NOLOCK. That works for them because they don't need simultaneous reader+writer access, and every tool of theirs uses the same wrapper code so their locks are always honored.
In short, this is not an LMDB bug to fix, it's entirely the responsibility of the software built on top of it.