Security vulnerabilities

Hello,

the platform default umask is `022`

That's not true, it's 0007.

Kind regards,
Cyril

Hello Cyril,

Could you reopen this — the closure premise ("default umask is 0007") doesn't match what the platform actually does. I re-measured on two accounts I own, in both the interactive login shell and a non-interactive bash -c 'umask':

$ umask
0022
$ bash -c 'umask'
0022

Files in /tmp therefore land world-readable (0644). Repro with two of my own accounts, A (steve-william, uid 530469, gid 486358) and B (test-domain, uid 530478, gid 486367) — different UIDs and groups, both on ssh1:

# as A
$ echo "SECRET_OF_A" > /tmp/canary.txt
$ stat -c '%U:%G %a' /tmp/canary.txt
steve-william:steve-william 644
# as B (a different customer)
$ cat /tmp/canary.txt
SECRET_OF_A

A and B are in different groups, so a 0660 file (what umask 0007 produces) wouldn't be readable across them — i.e. 0007 would fix this. The point is 0007 isn't what's applied: the shell/runtime umask is 0022. This isn't limited to my test files — as B, 69 files owned by other customers are world-readable in /tmp right now (e.g. nerudaarchives_codex 644 /tmp/omeka_db_env_2388891, storioscope_ssh 644 /tmp/storioscope-pre-security-final-20260701.tgz).

The exposure is a platform-side one: alwaysdata's default umask (0022) + a shared, non-polyinstantiated /tmp. The standard mitigation on multi-tenant shared hosts is a per-account /tmp (pam_namespace).

You can confirm in seconds on any account: umask (observe 0022), then find /tmp -maxdepth 1 -type f ! -user "$(id -un)" -readable | head.

Happy to provide a screen recording. Kind regards.

I can confirm that the umask was not set in the non-interactive case (and only in that case). I've made a change, can you confirm you no longer get a 0022 umask?

Hi,

Thanks for the quick turnaround. I've re-tested on ssh1 with two accounts I own
(steve-william, uid 530469, and test-domain, uid 530478 — a separate customer in a
different Unix group). Confirming your fix:

1. The umask is now 0007 in every shell context, including the non-interactive path
that was previously unset:

  
  ssh <host> umask        -> 0007   (non-interactive, non-login)
  bash -c  'umask'        -> 0007
  sh   -c  'umask'        -> 0007
  bash -lc 'umask'        -> 0007   (login)
  bash -ilc 'umask'       -> 0007   (interactive)
  
  Previously, all of these returned 0022.
  

2. A /tmp file created via the default umask (no explicit chmod) now lands at
660 (rw-rw—-) instead of 644 (rw-r–r–).
3. The original cross-tenant repro no longer works: account test-domain (different
group) attempting to read a default-umask file created by steve-william now gets
"Permission denied". The group bit doesn't help because the two accounts are in
different groups.

So the non-interactive umask issue is resolved — thank you.

One residual I want to flag in good faith, in case you're treating this as a full
close of F-01 rather than just the umask sub-issue: because /tmp is still a single
shared, non-polyinstantiated directory (1777), files written with an *explicit* mode
(chmod 644, open(…, 0o644), tar/unzip preserving archived perms, install -m 644,
etc.) still land world-readable and remain cross-tenant readable. Right now, from
test-domain, 68 other-tenant files in /tmp are still readable, including some that
look sensitive (e.g. a DB env file and source archives), and at least one tenant is
actively producing fresh 644/664 files — so this isn't only legacy data. umask only
sets the default; it isn't a ceiling.

If the goal is to close the class fully, polyinstantiating /tmp per account
(pam_namespace / per-account tmpdir) removes the shared-directory exposure entirely
and doesn't depend on every process honoring the umask.

Happy to re-test again if you make further changes. I did not access or copy any of
the third-party files referenced above — enumeration was metadata-only.

Having a per-account /tmp is a different issue. Anyway, a program that uses /tmp (instead of $TMPDIR, which is private) AND uses its own permissive umask would be clearly at fault anyway.

Can you open a support ticket to claim a small bounty for that non-interactive umask issue?

sure