[ajaysehwal]

By default we store all node data, including the ChannelMonitors, under /tmp/ldk_node. create_dir_all_private accepts an existing directory without checking who owns it or who can write to it. If another local user pre-creates it (e.g., mkdir -m 0777 /tmp/ldk_node) before our first start, they can read our state, replace or roll back the database, or plant a symlink (e.g., ldk_node.log -> ~/.bashrc) so we append log lines to a file of their choosing.

This hardens how we handle the storage directory:

• Add create_dir_all_private_checked, which on Unix refuses an existing directory that is owned by a user other than the current user or root, or that is world-writable (mode & 0o002). It's used for the configured storage_dir_path (SQLite and fs-store) and the default log directory. Failures surface as BuildError::StoragePathAccessFailed, with the cause logged.
• Open the default log file with O_NOFOLLOW, and refuse a SQLite database file that is a symlink. Explicitly configured log paths still follow symlinks, as before.
• Document that the default location is only for testing, and set a storage directory in the README and crate-level example.

Notes:

• Behavior change: group-writable directories (e.g., from fsGroup) and 0755 directories from older versions are still accepted. World-writable directories, or ones owned by another non-root user, are now rejected. The main case this could break is a root-owned 0777 directory used by a non-root process, such as a Kubernetes emptyDir. I can relax the world-writable check to apply only when we don't own the directory if that's a concern.
• The default stays /tmp/ldk_node. Moving it or refusing it on mainnet would be an API change, so I left that for a separate discussion.
• The check applies only to the configured storage directory, not to arbitrary log or seed paths (their parents may legitimately be shared), and it doesn't change the VSS/Postgres setup. It is racy by nature (check vs. use), but it closes the realistic pre-created-directory case.
• O_NOFOLLOW applies only to the default log file, since users may legitimately symlink their own log file, and failing there would hit the logger's expect on every write.
• Adds one unsafe { libc::geteuid() } call (it can't fail). No new dependencies: libc was already a direct dependency.

Tests: new unit tests cover directory checks (world-writable rejected, group-writable and own directories accepted), a symlinked SQLite database, a symlinked default log file (rejected) vs. a configured one (accepted), and Builder::build refusing a world-writable directory. cargo test --lib passes, and cargo check --lib compiles with uniffi and with storage-sqlite disabled. I didn't run the integration tests.

AI disclosure: prepared with the assistance of Claude Code.

[ldk-reviews-bot]

I've assigned @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[tnull]

I don't think this is worth it - users are responsible to handle access to the data folder. We can't fully protect them from messing up, and may also not have the full picture.

[ajaysehwal]

I don't think this is worth it - users are responsible to handle access to the data folder. We can't fully protect them from messing up, and may also not have the full picture.

Understood, that’s fair. Users own their data directory, and we can’t see the full picture of how it’s deployed, so I’ll drop the ownership and permission checks and the symlink handling. The one piece I’d still suggest is a short docs note that the default /tmp/ldk_node is only meant for testing, with the README and crate-level example setting a storage directory explicitly. It adds no behavior change. If you’d rather not have that either, I’m happy to close this.