- Notifications
You must be signed in to change notification settings - Fork914
fix(agent): filter outGOTRACEBACK=none#16924
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
With the switch to Go 1.24.1, our dogfood workspaces started setting`GOTRACEBACK=none` in the environment, resulting in missing stacktracesfor users.This is due to the capability changes we do when`USE_CAP_NET_ADMIN=true`.https://github.com/coder/coder/blob/564b387262e5b768c503e5317242d9ab576395d6/provisionersdk/scripts/bootstrap_linux.sh#L60-L76This most likely triggers a change in securitybits which sets`_AT_SECURE` for the process.https://github.com/golang/go/blob/a1ddbdd3ef8b739aab53f20d6ed0a61c3474cf12/src/runtime/os_linux.go#L297-L327Which in turn triggers secure mode:https://github.com/golang/go/blob/a1ddbdd3ef8b739aab53f20d6ed0a61c3474cf12/src/runtime/security_unix.goA better fix may be to read `/proc/self/environ` to figure out if thiswas set by the runtime or manually, but I'm not sure we should careabout that. A template author can still set the environment on the agentresource.Seehttps://pkg.go.dev/runtime#hdr-Security
| // Ignore GOTRACEBACK=none, as it disables stack traces, it can | ||
| // be set on the agent due to changes in capabilities. | ||
| // https://pkg.go.dev/runtime#hdr-Security. | ||
| if e == "GOTRACEBACK=none" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Is there any way for us to override this for ourselves that doesn't also override it for any user of coder? Seems like we're choosing for any user of coder that GOTRACEBACK shouldn't be set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
On Linux, we could theoretically read/proc/self/environ to figure out if it was set externally or by the Go runtime. I'm not sure it's worth the lift though.
If someone sets this env in, say, a docker container resource. Yes, it will be filtered out for child-processes (which arguably may be the right thing to do anyway). But if someone sets it on the agent resource (which is the recommended way anyway), they absolutely still can.
df92df4 intomainUh oh!
There was an error while loading.Please reload this page.
With the switch to Go 1.24.1, our dogfood workspaces started setting
GOTRACEBACK=nonein the environment, resulting in missing stacktracesfor users.
This is due to the capability changes we do when
USE_CAP_NET_ADMIN=true.coder/provisionersdk/scripts/bootstrap_linux.sh
Lines 60 to 76 in564b387
This most likely triggers a change in securitybits which sets
_AT_SECUREfor the process.https://github.com/golang/go/blob/a1ddbdd3ef8b739aab53f20d6ed0a61c3474cf12/src/runtime/os_linux.go#L297-L327
Which in turn triggers secure mode:
https://github.com/golang/go/blob/a1ddbdd3ef8b739aab53f20d6ed0a61c3474cf12/src/runtime/security_unix.go
A better fix may be to read
/proc/self/environto figure out if thiswas set by the runtime or manually, but I'm not sure we should care
about that. A template author can still set the environment on the agent
resource.
Seehttps://pkg.go.dev/runtime#hdr-Security