Secure cc-switch database and backup file permissions

[feiyehua]

Description
This PR tightens permissions around the cc-switch application database and related backup files.

Changes

• Create the app config directory and database file with restrictive permissions on Unix:
  • config/backups directories: 0700
  • database and backup files: 0600
• Detect existing insecure permissions before opening the database.
• Prompt interactive users before fixing existing permissions, and warn in non-interactive mode.
• Validate CC_SWITCH_CONFIG_DIR before database initialization, so library callers and non-CLI entry points also reject dangerous system directories like /, /etc, /usr, and /tmp.
• Ensure SQL backup files created by ConfigService::create_backup are written under secure backup directories and chmodded to owner-only access.

Limitations
All the permissions related code are for Unix. Permissions on Windows left onchanged (probably not a big problem?)

[unive3sal]

Hi @feiyehua

I'm doing a refactor for CI/CD. It will execute test cases on a sandbox (usually the directory will be set to /tmp). So Would you like to investigate if your commit will reject /tmp directory during cargo test?

Thanks

[feiyehua]

Hi @feiyehua

I'm doing a refactor for CI/CD. It will execute test cases on a sandbox (usually the directory will be set to /tmp). So Would you like to investigate if your commit will reject /tmp directory during cargo test?

Thanks

Seems CC_SWITCH_CONFIG_DIR=/tmp will be rejected, as we should not change the permissions of system folders (or store database in system folder, especially public ones.).
However current tests set CC_SWITCH_CONFIG_DIR a subfolder under /tmp so it works fine.
Currently some proxy related test fails, but they seems to be pre-existing.

[unive3sal]

hi @feiyehua

I don't think executing test cases under /tmp directory is a dangerous behavior. The reasons as follows:

• the default permission for /tmp directory is "1777". which means all of the user CAN read, write, and execution.
• The integration test cases should be executed in a sandbox, otherwise it will break the host configuration and corrupt the test processes.
• My current approach for CI/CD is setting all environment under /tmp

env HOME="$(mktemp -d)" CC_SWITCH_CONFIG_DIR="$HOME/.cc-switch" CLAUDE_CONFIG_DIR="$HOME/.claude" CODEX_HOME="$HOME/.codex" XDG_CONFIG_HOME="$HOME/.config" XDG_RUNTIME_DIR="$HOME/.runtime" XDG_STATE_HOME="$HOME/.state"

Therefore, I think /tmp directory should NOT be rejected.

[feiyehua]

hi @feiyehua

I don't think executing test cases under /tmp directory is a dangerous behavior. The reasons as follows:

• the default permission for /tmp directory is "1777". which means all of the user CAN read, write, and execution.
• The integration test cases should be executed in a sandbox, otherwise it will break the host configuration and corrupt the test processes.
• My current approach for CI/CD is setting all environment under /tmp

env HOME="$(mktemp -d)" CC_SWITCH_CONFIG_DIR="$HOME/.cc-switch" CLAUDE_CONFIG_DIR="$HOME/.claude" CODEX_HOME="$HOME/.codex" XDG_CONFIG_HOME="$HOME/.config" XDG_RUNTIME_DIR="$HOME/.runtime" XDG_STATE_HOME="$HOME/.state"

Therefore, I think /tmp directory should NOT be rejected.

This commit only rejects CC_SWITCH_CONFIG_DIR=/tmp. If this is allowed, database such as /tmp/cc-switch.db will be created, which is strange. If the users use CC_SWITCH_CONFIG_DIR=/tmp and cc-switch-cli creates something with incorrect permissions, then it is exposed to all other users.
However, subfolders under /tmp, such as ones that created by mktemp -d, are perfectly fine and will not be rejected.
Tested this folder and it works fine:

echo $HOME && echo $CC_SWITCH_CONFIG_DIR
/tmp/tmp.CkI8wm9hdm
/tmp/tmp.CkI8wm9hdm/.cc-switch

[feiyehua]

Pushed a new version that only checks permissions when app starts up. This ensures permission check runs only once and will not broke TUI.
Also add tests

[SaladDay]

Thanks for the work here. The direction makes sense, but I do not think this PR is ready to merge yet. I found two blocking issues around the permission boundary.

Blockers:

1. CC_SWITCH_CONFIG_DIR validation can be bypassed with .., and can chmod an unexpected parent directory.

validate_config_dir() falls back to the original path when canonicalize() fails. A path like <tmp>/child/.. passes validation if child does not exist yet. Later, create_secure_dir_all() creates child, then treats child/.. as an existing directory and applies restrict_dir_permissions() to it.

I reproduced this safely in a temporary directory:

config_dir=<tmp>/child/..
validate=Ok("ok")
before=0755
Database::init()=Ok("ok")
after=0700

So the current check rejects literal /tmp, but an equivalent path such as /tmp/new-child/.. can still pass and may end up chmodding /tmp itself. This needs robust normalization/canonicalization before any permission mutation, and paths containing unresolved .. should not be allowed to drive chmod behavior.

2. The dangerous-directory validation is only wired into the CLI entrypoint, not the database initialization boundary.

The PR description says validation happens before database initialization so library callers and non-CLI entry points also reject dangerous directories. In the current code, validate_config_dir() is called from main.rs, but Database::init() itself does not call it.

I verified this with a minimal external caller:

CC_SWITCH_CONFIG_DIR=/tmp
cc_switch_lib::Database::init() -> INIT_OK

There is also a CLI-internal bypass: main.rs excludes Internal commands from database_access_required(), but internal capture-codex-temp calls AppState::try_new(), which reaches Database::init() without the new validation/prompt path.

This validation should live at the core DB/app-state initialization boundary, or every DB-opening entry point must be proven to go through the same guard.

Non-blocking but worth fixing while here: existing backup files under backups/ are not checked or repaired. The PR secures newly created backup files, but check_permissions() only checks the config dir, cc-switch.db, and the backups directory. Existing world-readable .sql / .db backups would remain exposed without warning.

I would hold merge until the two blockers above are fixed and covered by focused tests.

[feiyehua]

@SaladDay fixed these problems. Now:

• Extracted a new resolve_existing_or_new_child_path() function that handles the case where the final
  path component doesn't exist:
  • Splits the path into parent + filename.
  • Canonicalizes the parent (which must exist), then re-appends the filename.
  • If the parent also fails to canonicalize, returns an error.
• Log if Database::Init() detect insecure permissions

---

2 tests failing, seems caused by incorrectly dropping newly created temp test home:
cli::tui::app::tests::tests::prompt_create_runtime_clears_filter_when_new_prompt_is_not_visible
cli::tui::app::tests::tests::prompt_save_runtime_creates_prompt_from_one_page_form
fixed

[SaladDay]

@feiyehua This PR looks directionally good to continue. The main blocker right now is that it conflicts with the latest main. Could you please rebase onto the current main and resolve the conflicts? I can take another pass after that. Thanks!