You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi! We've looked at your proxy for tensorboard and it's quite nice (just a single file to deploy, no muss no fuss, etc). But tensorboard is still reachable if one knew the port.
I've got a branch here that uses unshare to create a new network namespace so that tensorboard can boot in it and stay unreachable. Of course this relies on the users ability to use unshare (they need access to subuids) which isn't enabled in most systems.
This ticket is just to let you know of that work, and that we've modified your authrevproxy (and copied your license and noted these facts in the README). The modifications were mostly just updates to use python3, twisted 19 and enable being run by root.
Let me know if the licensing in that branch is what you'd expect (or if you want me to cease and desist and remove it entirely. as it's GPL I'm happy to push whatever updates you'd like back here).
The text was updated successfully, but these errors were encountered:
@johrstrom Thank you very for letting us know about your improvement!
It's true that although the tensorboard process is bound to the local 127.0.0.1 address and can't be access from another host, any process running on the same node could still bypass the authenticating proxy and access the Tensorboard interface directly, unauthenticated. Using unshare to avoid that issue sounds like a good idea when it's available.
Maybe a further improvement would be to try to detect if users can run unshare and if the required tools are available in the current environment , and if not, fall back to the previous behavior? That way, this security measure could be implemented if the host setup allows for it, but the app would still work when unshare can't be used?
No problem for the license, it's perfect as it is, and thanks for crediting us!
Hi! We've looked at your proxy for tensorboard and it's quite nice (just a single file to deploy, no muss no fuss, etc). But tensorboard is still reachable if one knew the port.
I've got a branch here that uses unshare to create a new network namespace so that tensorboard can boot in it and stay unreachable. Of course this relies on the users ability to use unshare (they need access to subuids) which isn't enabled in most systems.
This ticket is just to let you know of that work, and that we've modified your authrevproxy (and copied your license and noted these facts in the README). The modifications were mostly just updates to use python3, twisted 19 and enable being run by root.
Let me know if the licensing in that branch is what you'd expect (or if you want me to cease and desist and remove it entirely. as it's GPL I'm happy to push whatever updates you'd like back here).
The text was updated successfully, but these errors were encountered: