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

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.

Start with deploy/install.sh and deploy/install-mtproxy.sh, then inspect TestLoadAcceptsSystemdCredentialReadPermissions in internal/config/config_test.go. Reproduce the failures under umask 077, run go test ./..., and check the installed MTProxy tree and mtproxy.service. Done means the test gate passes, MTProxy starts as its service user, and /readyz returns 200.