Feb 21, 2017 18:46:17 UTC

by Joel C

While this is a great module for users running commandbox on a windows-based OS, you have to run commandBox as root for any other platform. Starting CommandBox as root means that every server instance (runwar/undertow/java) runs as root a and every shell command you execute is in the context of root. (It also means Brad's awesome tilde (~) home dir mapping points to the root user's home dir, which may have unexpected results for custom scripts and interceptors/modules others have written that make use of the ~ awesomeness) Make no mistake though... This is no fault of the module developer. Chris did an excellent job on this module and I'm not trying to take anything away from his success. This problem stems from a security feature that was implemented in the Unix kernel's network stack a long time ago. You can only bind to TCP ports 0-1023 as the root user. That way, a regular user cant start up a rogue service on port 22, for example, pretending to be the secure shell service (sshd) It made more sense back then it does now and I wish they'd remove it from the kernel altogether. Of course, Chris would still need root permissions to add entries to /etc/hosts... :) I think it would be wonderful to have a "sudo"-like command built into CommandBox! A "pseudo sudo", if you will. This would allow Chris to execute the code for modifying the /etc/hosts file as the root user without the need to start commandBox itself as root. He could even launch a separate process to listen on port 80 (as root) and forward that traffic to the server's non-root port (>1023) when a server is started. Port forwarding is probably the best solution for the Unix 0-1023 port binding "feature" as it would have the most compatibility with MacOS and *nix. (versus, say, authbind, which isn't avail on the MacOS) Wishful thinking? Maybe. Can anyone convince me that running CB as root isn't all that bad though?

Feb 21, 2017 21:46:03 UTC

by Brad Wood

Hey Joel, we actually have a working proof of concept to do exactly what you described. The difference is instead of using CFML to manipulate the hosts file, we have to do it in a bash sudo one liner that we fire off with the Java equivalent to cfexecute. It's difficult to get working though mostly because neither Chris nor I own a Mac to test on.

Feb 22, 2017 10:30:18 UTC

by Joel C

Hi Brad, I have a Macbook pro sitting on my desk running macOS Sierra. (10.12.2) I'll do whatever you need to support this endeavor. Funny story. I actually wrote a very similar module to the one Chris wrote. I did this on windows and it works flawlessly there. Unfortunately, it bombed on macOS. That's actually the reason I have this macbook now. I'm trying to solve the same problem and I'm not getting very far. My macbook and I are at your disposal. Just let me know what you need. I cloned Chris' github repo but don't see these changes. Thanks! Joel

Feb 17, 2020 13:12:58 UTC

by Jeff Jones

Brad, did you ever get this working with the proposed permission changes?

Feb 17, 2020 16:22:47 UTC

by Bradley D Wood

Jeff, I actually can't remember. I think we added something, but since I'm not a Mac user, I never ran into it. I'm pretty sure it runs sudo now and you either have to put in your password or set your suders to not require a password on *nix. This has always been a community extension so I never had access to change the source directly since someone else owns the project.

Feb 17, 2020 20:41:29 UTC

by Jeff Jones

Thanks Brad. Being a Linux user, I will have to look into this. I found this while on my Windows box at work, but I don't use Windows anywhere else.