Files
pgadmin4/web
Ashesh Vashi fb9ce563fb fix: tighten DATA_DIR file/dir permissions at creation
Two related hardening changes around the pgAdmin data directory:

1. Atomic 0o600 for pgadmin4.db
   ----------------------------
   pgadmin/__init__.py:run_migration_for_sqlite() and
   setup.py:setup_db()'s run_migration_for_sqlite() previously chmod'd
   pgadmin4.db to 0o600 *after* SQLAlchemy/SQLite created it via
   db_upgrade(). With a typical 0o022 umask, the file existed at 0o644
   between SQLite's create and pgAdmin's chmod — a TOCTOU window.
   Practically narrow because the parent dir is 0o700, but easy to
   close: wrap the migration call in `os.umask(0o077)` so the file is
   born 0o600. Both code paths use try/finally so the prior umask is
   restored even on migration failure (a raise during db_upgrade no
   longer leaves the rest of the worker running with 0o077 in effect).
   The post-hoc chmod is kept as belt-and-suspenders for the case where
   the file already existed at a wider mode from an older install.

2. 0o700 for sensitive DATA_DIR subdirectories
   --------------------------------------------
   setup/data_directory.py previously chmod'd only SESSION_DB_PATH and
   the parent dir of SQLITE_PATH to 0o700. STORAGE_DIR (user uploads
   including saved cloud-deployment certs/keys), AZURE_CREDENTIAL_CACHE
   _DIR (MSAL token cache files — real Azure credentials), KERBEROS_
   CCACHE_DIR (Kerberos credential caches), and the directory holding
   pgadmin4.log (stack traces frequently capture sensitive context)
   were left at umask-default (typically 0o755 — directory listing
   readable by any local user).

   Refactor the create-loop to track which directories were newly
   created on this invocation, then apply chmod 0o700 uniformly to all
   sensitive dirs at once. Errors (e.g., chmod on a mounted volume in
   OpenShift) emit a WARNING but don't abort — same lenient pattern the
   existing SQLITE_PATH-dir chmod already used.

   pgadmin4.log itself is still 0o644 (umask-default) because Python's
   logging.FileHandler doesn't take a mode argument; tracked as a
   follow-up task to subclass the handler.
2026-05-01 16:38:49 +05:30
..
2026-01-05 13:33:45 +05:30
2022-04-01 17:22:16 +05:30
2026-01-05 13:33:45 +05:30
2026-01-05 13:33:45 +05:30
2026-01-05 13:33:45 +05:30
2026-03-30 17:44:32 +05:30