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

Document OS X limitations with inject-tcp method #268

dylanscott opened this Issue Aug 9, 2017 · 3 comments


None yet
2 participants

dylanscott commented Aug 9, 2017

Hey there, really appreciate this tool! We're hoping to use it to revamp the development of our services and it seems really promising.

While setting this up I ran into a pretty big pitfall around the interaction between the inject-tcp method and OS X's System Integrity Protection feature. I was thinking it might be worth documenting this to save other people some time when setting this up.

It looks like in OS X El Capitan Apple introduced a feature called System Integrity Protection (SIP). This feature prevents, among other things, code injection into processes that originate from certain designated "protected directories" (including /usr and /bin). This includes purging dynamic linker environment variables for these processes. These protections are in place even when running as root. They can only be disabled by booting into recovery mode, and disabling them is highly discouraged.

It turns out that in practice it can be really hard to prevent some types of processes from at some going through a protected binary. We're using Telepresence to swap out services for a locally built version and build tools very frequently invoke shell scripts (which either directly invoke something like /bin/sh or indirect through/usr/bin/env, both of which are protected). Also in the Node world any "executable module" typically is actually a script starting with #!/usr/bin/env node.

We can't use the vpn-tcp method (being able to swap only one service at a time is a non-starter for us), so I'm planning on working around this in a fairly hacky way (adding hosts entries for our service names that point to the cluster). This hopefully won't actually be too bad since it will also eliminate some of the other drawbacks to the inject-tcp method (statically linked binaries and such), but I'm curious if anyone else has run into this and worked around it in a different way.


This comment has been minimized.


ark3 commented Aug 10, 2017

Thanks for the detailed information. This is a great starting point for improved documentation.

  1. The methods documentation would benefit greatly from having more information about Mac-specific limitations. I can start by adapting what you posted above, but we could use your help!

  2. We have some ideas about how Telepresence could proxy multiple services to the local machine with the vpn-tcp method, at least under certain circumstances. I'd like to understand your use case a little more clearly so I can focus my initial efforts. Would it be okay to pick up a phone call, chat in Gitter, or something along those lines?

@ark3 ark3 added the documentation label Aug 15, 2017


This comment has been minimized.


ark3 commented Aug 15, 2017

Just to clarify, Telepresence attempts to work around SIP to some extent by creating duplicates of /bin, /usr/bin, etc. and putting those in the PATH instead of the SIP-protected originals. This allows the user to type something like env ENABLE_FROBULATE=1 ./my_binary and get the benefits of inject-tcp. What does not work is running a tool or script that has a full path to /bin/sh or /usr/bin/env or similar, since Telepresence cannot manipulate those commands when located in those protected directories.

@ark3 ark3 self-assigned this Aug 15, 2017


This comment has been minimized.


ark3 commented Aug 16, 2017

I updated the docs in 46a020f based on your detailed write-up. Thanks again.

@ark3 ark3 closed this Aug 16, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment