fix(cli): keep --allow / profile network rules working under --proxy-user#97
Merged
Conversation
greyproxy associates a proxied connection with its session — and thus enforces that session's network rules, including --allow — by matching the SOCKS5 login against the session container_name. These were derived independently: the login was proxyUserFlag || cmdName || "proxy", while the container name was cmdName || "sandbox". With --proxy-user set (or an empty cmdName) the two diverged, so --allow and profile network rules were silently registered under a container no live connection ever logged in as. Derive both from a single proxyIdentity helper so they can never diverge, and add a regression test pinning the --proxy-user case.
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.
Fixes #96.
Problem
greyproxy associates a live proxy connection with its session — and therefore enforces that session's network rules, including
--allowand profilenetwork.rules— by matching the SOCKS5 login against the sessioncontainer_name(docs/templates.md:88,100; the--proxy-userhelp atmain.go:132calls this "match per-client rules by login"). The randomsessionIDis never sent over the proxy connection, so the login is the only identifier tying the connection to its rules.These two values were derived independently in
runCommand:proxyUser)proxyUserFlag??cmdName??"proxy"container_namecmdName??"sandbox"They matched for an ordinary
greywall -- curl …run, but diverged when:--proxy-user Xwas set (loginX, containercmdName) — the flag added in feat(cli): --proxy-user to inject a caller-chosen SOCKS5 username #87, after the session-rules feature Session-scoped network rules from profiles #80, so this regressed silently;cmdNamewas empty (login"proxy", container"sandbox").In those cases the
--allow/profile rules were registered under a container name that no live connection ever authenticated as, so greyproxy never applied them and the traffic was blocked despite the explicit allow.Fix
Introduce a single
proxyIdentity(proxyUserFlag, cmdName)helper and derive both the proxy-URL login and theRegisterSessioncontainer_namefrom it, so they can never diverge.Test
TestProxyIdentity(cmd/greywall/main_test.go) pins the precedence; the--proxy-usercase (proxyIdentity("agent1","curl") == "agent1") is the regression guard — the old container-name derivation would have produced"curl".Verification
go test ./cmd/greywall/✅make lint→ 0 issues ✅go build ./...✅