www user on port 80 (launchd)

[DenBeke]

Is it possible to let run a process without root permissions and let it bind to port 80?
I want to run a webserver on port 80 as www user using launcd.

 

[UniqueUserName]

Is it possible to let run a process without root permissions and let it bind to port 80?
I want to run a webserver on port 80 as www user using launcd.

Any process trying to bind to a port below 1024 must be running as superuser

You could write a script as root that gets the set permission ID bit set to "S" and launch the script as www, though. It would gain superuser access.

 

[DenBeke]

Any process trying to bind to a port below 1024 must be running as superuser

I know, but on Linux or BSD, you can use setcap to make it possible to bind to port 80.

You could write a script as root that gets the set permission ID bit set to "S" and launch the script as www, though. It would gain superuser access.

Any more concrete info about this?

Or do you mean this?
chmod +S ./myapp

 

[UniqueUserName]

I know, but on Linux or BSD, you can use setcap to make it possible to bind to port 80.




Any more concrete info about this?

Or do you mean this?
chmod +S ./myapp

Yah, chmod u+s ./myapp. (I think it's lower cased s, may be upper). Make sure myapp is owned by root. That should do it, you can launch it as www but it will run with root permissions. Of course, that means that if someone could shell out of myapp to a command prompt, it'd be root.

 

[hughm123]

The normal procedure for a web server is to start as root but then switch to a different user/group after binding to the reserved port(s). It's *very important* to not just run as root, otherwise anyone accessing the web server can read any file it can read as root. For example in the bundled /etc/apache2/httpd.conf:

# If you wish httpd to run as a different user or group, you must run
# httpd as root initially and it will switch.
#
# User/Group: The name (or #number) of the user/group to run httpd as.
# It is usually good practice to create a dedicated user and group for
# running httpd, as with most system services.

User _www
Group _www​

Rather than running your own solution, Mac OS already includes Apache2 and I'd strongly recommend you use the existing Apache server. It looks like setup instructions are under https://discussions.apple.com/docs/DOC-3083, although this page is complicated because it refers to PHP and mod_perl which you may not need.

In the end though it looks like you start the server on a client version of OS X with:
sudo launchctl load -w /System/Library/LaunchDaemons/org.apache.httpd.plist

Important warning:

You may already know this, but if you run a web server with incorrect config it may allow random people to read files on your system. So you should check/edit the config files under /etc/apache2, including the master file under /etc/apache2/httpd.conf before starting the server. If your system is not accessible from the public internet then this may be OK, but if you enable the web server on a laptop and then use the laptop in Starbucks, you should make sure the config is safe.

 

[MacUser2525]

Rather than running your own solution, Mac OS already includes Apache2 and I'd strongly recommend you use the existing Apache server.

Indeed I was reading this question trying to figure out just why anyone needed to do anything else. It already binds to port 80 and using its default configuration of using the Sites directory in the users home directory it is restricted to accessing/running files from only there in that directory unless you go out of your way to configure it otherwise.

 

[DenBeke]

Thanks for the input, @MacUser2525 and @hughm123.
Why running my own webserver? Since there is Caddy, a very simple yet powerful webserver written in Go. It allows me to have automatic HTTPS using Let's Encrypt and a bunch of very useful plugins.
I could of course use the built-in Apache server. But once you're used to automated certificate signing and easy config (ok,surely that using OS X server built-in panel is more easy in some cases) you don't want anything else...

I'm already running Caddy on Linux using the setcap command. And I hoped I could do the same on OS X.

 

[MacUser2525]

According to the getting started guide of the program the default port for it is 2015 there is no law saying any daemon running has to run on the port that you find in listings are reserved for them like 80 for http, it even shows example for 8080 the backup port for http for people running home web servers when their ISP blocks 80. All you need to do is configure it to use a port that you can access like the 8080 then your website would be https://123.456.789.012:8080 since you want that. I think it is 9090 that is the backup port for the https you would want now I think on it having just typed that.

https://caddyserver.com/docs/getting-started

 

[hughm123]

Thanks for the input, @MacUser2525 and @hughm123.
Why running my own webserver? Since there is Caddy, a very simple yet powerful webserver written in Go. It allows me to have automatic HTTPS using Let's Encrypt and a bunch of very useful plugins.
I could of course use the built-in Apache server. But once you're used to automated certificate signing and easy config (ok,surely that using OS X server built-in panel is more easy in some cases) you don't want anything else...

I'm already running Caddy on Linux using the setcap command. And I hoped I could do the same on OS X.

You can use letsencrypt with Apache on MacOS - you need to install "certbot" via Homebrew and then instructions are under https://certbot.eff.org/#osx-apache.

Obviously if you're used to Caddy then switching to Apache's different config files is non-zero effort. But as @MacUser2525 says, you can ruin caddy server on a different port. For example 8080 used to be common as an alternative to "80" for non-priviliged servers, and maybe also 9090 (for HTTPS?)

 

[DenBeke]

According to the getting started guide of the program the default port for it is 2015 there is no law saying any daemon running has to run on the port that you find in listings are reserved for them like 80 for http, it even shows example for 8080 the backup port for http for people running home web servers when their ISP blocks 80. All you need to do is configure it to use a port that you can access like the 8080 then your website would be https://123.456.789.012:8080 since you want that. I think it is 9090 that is the backup port for the https you would want now I think on it having just typed that.

https://caddyserver.com/docs/getting-started

Port 2015 is just an example for a port...
And running it on other ports is not what I intend to do, it's inconvenient for users.
But thanks for all the input.

 

[hughm123]

Port 2015 is just an example for a port...
And running it on other ports is not what I intend to do, it's inconvenient for users.
But thanks for all the input.

One other comment: you might be able to do port forwarding, for example see http://serverfault.com/questions/102416/iptables-equivalent-for-mac-os-x which seems to be an example of someone doing this type of web server port forwarding. Also http://knowm.org/port-forwarding-80-to-8080-using-ipfw-on-mac-os-x/.

Disclaimer: I'm personally using Apache on Linux, so cannot confirm this will work in your case, but it may. For example there is some suggestion you should use "pfctl" in future instead.

The Caddy docs are clear that they don'y support starting as root and then switching to another user, but they do mention port forwarding as another option:

Do I have to run Caddy as root to serve on port 80 or 443?
No. On Linux, you can use setcap to give Caddy permission to bind to low ports. [....] You could also use iptables to forward to higher ports.

Privilege de-escalation is another option, but it is not yet a reliable solution. It will be implemented as soon as this becomes a robust possibility. Concerned readers are encouraged to get involved to help this become a reality.​

 

[kiwipeso1]

On standard mac without server, you just start sharing your personal website in each users folder.
On Mac OS Server, you just start the server app and switch on webserver or wiki server service.

For letsencrypt, the process is homebrew, then autocert. (as mentioned above.)