install.sh: umask 077 fails the test gate and installs an unexecutable MTProxy (203/EXEC)

[alexelagov]

deploy/install.sh sets umask 077 on line 3. Two things downstream inherit it and break, so the stock installer cannot complete on a clean machine. Both are reproducible from a fresh clone.

Environment: Ubuntu 22.04.5 LTS, x86_64, commit 52a5feb7fac38f68da5afef9cedd9b3bfc8473ca.

1. go test ./... fails, aborting the install

install.sh runs the suite at line 146:

(cd "$repository" && "$go_binary" test ./...)

TestLoadAcceptsSystemdCredentialReadPermissions creates the profiles file with os.WriteFile(profiles, []byte(content), 0444). Go applies the process umask, so under umask 077 the file lands as 0400 instead of 0444. The test then unsets CREDENTIALS_DIRECTORY and asserts that Load rejects a group/other-readable file — but nothing is group/other-readable, so Load correctly accepts it and the assertion fires:

--- FAIL: TestLoadAcceptsSystemdCredentialReadPermissions (0.00s)
    config_test.go:248: group/other-readable profiles file outside a credential directory was accepted
FAIL	github.com/telegramdesktop/tproxy-server/internal/config

With set -euo pipefail the installer stops here, before writing any configuration.

Confirmed to be umask and nothing else — same tree, same binary, back to back:

$ (umask 077; go test ./internal/config/)
--- FAIL: TestLoadAcceptsSystemdCredentialReadPermissions
FAIL	github.com/telegramdesktop/tproxy-server/internal/config	0.013s

$ (umask 022; go test ./internal/config/)
ok  	github.com/telegramdesktop/tproxy-server/internal/config	0.008s

The robust fix is in the test — an explicit os.Chmod(profiles, 0444) after os.WriteFile makes the fixture independent of the caller's umask. Scoping the test run in the installer ((umask 022; cd "$repository" && "$go_binary" test ./...)) also works, but only papers over a test that silently changes meaning with the environment.

2. MTProxy is installed unexecutable, mtproxy.service fails 203/EXEC

deploy/install-mtproxy.sh inherits the same umask. make therefore creates objs/ and objs/bin/ as 0700 and the binary as 0700, and chown -R root:root "$build_directory" then makes them root-owned before the tree is moved to /opt/MTProxy:

drwx------  root root  /opt/MTProxy/objs
drwx------  root root  /opt/MTProxy/objs/bin
-rwx------  root root  /opt/MTProxy/objs/bin/mtproto-proxy

mtproxy.service runs with User=mtproxy, which can neither traverse objs/bin nor execute the binary:

mtproxy.service: Main process exited, code=exited, status=203/EXEC
mtproxy.service: Failed with result 'exit-code'.
mtproxy.service: Scheduled restart job, restart counter is at 13.

This one is quieter than the first, because the installer itself keeps going and only fails at the very end with a message that points somewhere else:

tproxy-server did not become ready

tproxy-server and caddy are both healthy at that point (/healthz returns 200); it is /readyz returning 503 backend unavailable because there is no reachable MTProxy on 127.0.0.1:2398. The install looks like a relay problem when the actual cause is file permissions three directories away.

umask 022 in install-mtproxy.sh, or an explicit chmod of the installed tree, resolves it. After

find /opt/MTProxy -type d -exec chmod 0755 {} +
chmod 0755 /opt/MTProxy/objs/bin/mtproto-proxy

mtproxy.service starts normally and /readyz returns 200.

Note

Since umask 077 is set by the installer itself rather than by the operator, both failures should reproduce on any clean Ubuntu 22.04+ / Debian 12+ host following the documented quick start.

[sandamond]

Independently hit both of these deploying to a fresh Ubuntu 26.04 host at the same commit — so this isn't 22.04-specific, it reproduces across at least two LTS releases apart.

For what it's worth, we initially shipped the "papers over it" fix you describe (umask 022 around the test invocation, plain chmod -R a+rX on the MTProxy build output) in our own downstream fork, then switched to the robust version once we saw #9 and #12 already had it: explicit os.Chmod(profiles, 0444) in the test itself, and a chown root:mtproxy / chmod 0750 on objs, objs/bin, and the binary (matching the root:mtproxy 0750 scheme this installer already uses for /etc/mtproxy, and narrower than a blanket a+rX on the whole tree) run unconditionally so a host left in a bad state by an earlier interrupted build gets repaired on the next run instead of staying broken. Both fixes read as correct to us and match each other almost line for line, for whatever that's worth in choosing between them.