-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove feature flag for VNet launch daemon #44923
Conversation
@@ -80,4 +80,5 @@ enum BackgroundItemStatus { | |||
BACKGROUND_ITEM_STATUS_ENABLED = 2; | |||
BACKGROUND_ITEM_STATUS_REQUIRES_APPROVAL = 3; | |||
BACKGROUND_ITEM_STATUS_NOT_FOUND = 4; | |||
BACKGROUND_ITEM_STATUS_NOT_SUPPORTED = 5; |
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.
Negative values for enum are supported but not recommended, so I just used 5
instead. On top of that, BackgroundItemStatus
in protos already doesn't map 1:1 to the actual status returned by macOS, because 0
returned by macOS means "not registered", whereas in protos 0 should be reserved "unspecified".
5befd7a
to
949c9ad
Compare
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
🤖 Vercel preview here: https://docs-9ycc1w2ah-goteleport.vercel.app/docs/ver/preview |
@ravicious See the table below for backport results.
|
This PR also updates the docs to reflect this change.
On top of that, it makes sure that osascript can't be used for VNet if tsh was compiled with launch daemon support. I wanted to keep osascript as a fallback, configurable through a flag in the config, in case the launch daemon implementation turned out to be faulty. But now that we insecurely pass euid and egid through argv when osascript is used (#44751), it really is only meant to be used in development.
I also made sure that the notification about enabling the background item is not shown on macOS < 13.0 which does not support
SMAppService
. We already returned-1
as the daemon status in that scenario, but when converting it to a gRPC enum it got translated to theUNSPECIFIED
variant and then the logic was faulty as well – we showed the notification as long as daemon status wasn'tENABLED
. I added an explicitNOT_SUPPORTED
variant.changelog: Added a background item for VNet in Teleport Connect; VNet now prompts for a password only during the first launch