Document tproxy-keys and fix two installer umask bugs - #2
Merged
Conversation
deploy/install.sh sets umask 077 for the whole script. Two consequences of that only show up on a clean host, so the reference installer as written does not actually complete there: - go test ./... inherits umask 077, which makes a config-package test fixture written 0444 come out 0400. That makes TestLoadAcceptsSystemdCredentialReadPermissions fail (it depends on a fixture that is genuinely group/other-readable), aborting the install before anything is built. Run the suite under umask 022 instead. - deploy/install-mtproxy.sh inherits the same umask when it builds official MTProxy, so the installed binary comes out 0700 root:root. mtproxy.service execs it as the unprivileged mtproxy user, which then can't read or run its own binary and fails with status=203/EXEC. chmod -R a+rX the build output before installing it. Both are reproduced and fixed against a real Ubuntu 26.04 host in this session; go test ./... is re-verified failing under 077 and passing under 022 on this exact tree as part of this change. Also: - keys-panel/README.md documents tproxy-keys end to end: why it exists, what `add`/`revoke`/`rotate` actually do, install steps, the CLI and web UI, the security model, and known limitations. - Cross-links it from README.md's "Multiple secrets on one hostname" section, where hand-editing profiles.json is otherwise the only documented option. - install.sh now detects tproxy-keys's MTProxy drop-in (/etc/systemd/system/mtproxy.service.d/secrets.conf) and, if present, runs `tproxy-keys sync` after profiles.json is rewritten. Without this, a reinstall resets profiles.json to a single default profile but leaves MTProxy's actual secret list (which tproxy-keys maintains separately) stale, so the two would disagree about which secrets are valid. This does not preserve keys added through the panel across a reinstall — profiles.json still gets reset, as documented — it only keeps MTProxy consistent with whatever profiles.json ends up holding. keys-panel/README.md spells out the backup/restore steps for keeping a key set across a reinstall. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
deploy/install.sh/deploy/install-mtproxy.shbugs that make the reference installer fail outright on a clean Ubuntu 26.04 host, both traced to the script's ownumask 077:go test ./...inherits it, so a config-package test fixture written0444comes out0400andTestLoadAcceptsSystemdCredentialReadPermissionsfails — the install aborts before anything is built. Fixed by running the suite underumask 022.0700 root:root;mtproxy.serviceexecs it as the unprivilegedmtproxyuser and fails withstatus=203/EXEC. Fixed withchmod -R a+rXon the build output before install.keys-panel/README.md: whattproxy-keysdoes and why, install steps, CLI + web UI reference, security model, and known limitations (no per-key stats, no hot reload, single MTProxy backend).README.md's "Multiple secrets on one hostname" section.install.shnow detectstproxy-keys's MTProxy drop-in and runstproxy-keys syncafter rewritingprofiles.json, so a reinstall doesn't leave MTProxy's actual secret list stale relative to the freshly-resetprofiles.json. This does not preserve extra keys across a reinstall —profiles.jsonstill resets to a singledefaultprofile, that part of the installer's behavior is unchanged and already documented — it only keeps MTProxy consistent with whateverprofiles.jsonends up holding. The backup/restore steps for keeping a key set across a reinstall are inkeys-panel/README.md.Test plan
go test ./...fails with the documented error underumask 077, passes cleanly underumask 022gofmt -l .,go vet ./..., andgo build ./...clean for both the relay module andkeys-panel/bash -non both changed shell scriptsdeploy/install.shre-run against a deployed host withtproxy-keysinstalled — not done in this PR: the test server now has real, in-use family keys beyonddefault, and a live reinstall resetsprofiles.jsonto justdefault. Recommend running this once deliberately (with aprofiles.json/meta.jsonbackup perkeys-panel/README.md) rather than as an incidental side effect of merging.🤖 Generated with Claude Code