Files
ObsidianDragon/third_party
DanSandClaude Opus 5.5 39333f80b7 fix(lite-backend): keep wallet files and logs private to the owner
On Linux and macOS the Lite data dir (~/.silentdragonxlite) was created
with create_dir_all (0755 under the default umask) on every
get_zcash_data_path() call, even by the startup wallet_exists() probe.
do_save wrote the wallet through File::create (0644) and renamed it into
place, and fs::copy gave the .bak the same mode, so any local account
could read the wallet file, and the plaintext seed with it when the
wallet was not encrypted. The debug log was 0644 and its roller pattern
was relative, so rolled logs landed in the process's working directory.

A crash-leftover .dat.tmp was truncated and reused: an fd another
account had opened on it read the next wallet. And after encrypt(), the
first save copied the previous, plaintext wallet to .bak, where the seed
stayed until the next save, or for good if the app quit right away.

- New helpers, each an item-level #[cfg(unix)] / #[cfg(not(unix))]
  pair: create_private_dir_all (0700 components), tighten (strips only
  the group/other bits of an existing dir or file, keeps the owner bits,
  never follows a symlink), create_private_file_new (unlinks a stale
  file, then create_new with 0600), and a once-per-process warning when
  a chmod fails (drvfs, FAT, NFS).
- get_zcash_data_path creates the default data dir 0700 and tightens an
  existing one (for test/regtest also its parent). A caller-supplied
  data_dir is created as before and never chmodded, and the params dir
  is left alone.
- do_save writes a fresh 0600 temp file and tightens the .bak after the
  copy. At the plaintext -> encrypted transition (the wallet is
  encrypted and the on-disk header says plaintext) the .bak is copied
  from the new, encrypted file. wallet_header_encrypted reads the flag
  byte for versions 4 and 6-9 only (v5 is gzip) and returns None when it
  cannot tell, which keeps the old behaviour.
- read_from_disk tightens a wallet restored from .bak, and the wallet
  and .bak after every successful read.
- get_log_config pre-creates the log 0600 on unix and anchors the
  roller in the data dir; a data path containing "{}" keeps the old
  relative pattern. log4rs re-creates the log with the umask mode after
  a 5 MB roll, so the 0700 data dir is the lasting control.

Flagged behaviour changes:
- on unix, the data dir is 0700 and existing files lose their
  group/other bits (owner bits kept, symlinks and a caller-supplied
  data_dir untouched); a shared group or a backup user under another uid
  loses read access;
- a fresh 0600 temp file is used;
- the first encrypted save backs up the encrypted file;
- the log rolls inside the data dir (old rolled logs in former working
  directories are not cleaned up).
On Windows the file modes are unchanged; the encrypted first .bak and
the log-roll location apply there too. Wallet format v9 is unchanged;
no ABI or symbol change.

Tests: the wallet and .bak are 0600 after every save and after an open
from 0644, and a wallet restored from a loose .bak is 0600, while the
caller's 0755 data dir is unchanged; a stale 0644 .dat.tmp is replaced
by a new inode and an fd held on it still reads the stale bytes; tighten
keeps owner bits (0555 -> 0500), ignores the other kind and symlinks,
create_private_dir_all makes every component 0700, and
create_private_file_new never reuses or follows a stale file or link;
after encrypt the first save's .bak is encrypted, byte-identical to the
wallet and unlocks to the seed; the header probe answers only for v4 and
v6-v9; the log is 0600, the roller pattern and a real roll stay in the
data dir, and a "{}" path falls back. An opt-in test
(DRAGONX_LITE_SCRATCH_HOME=1, temp HOME) checks the default data dir,
its testnet parent, a symlinked data dir and the params dir.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-12 13:22:00 -05:00
..