Hacker News Reader

Comment by ape4 | Hacker News Reader

Apache needs to start as `root` but then drops to an non-privileged user. systemd's `User=<user>` can't really express that. Perhaps an option that says a unit needs to be root until the first fork when it has to be a specified user. `ForkUser=apache`

View on HN

I don't know about httpd specifically, but many applications want root only to be able to bind to a privileged port (like :80). This can be circumvented in one of a few ways:

1. add this to .service

  AmbientCapabilities=CAP_NET_BIND_SERVICE

2. or listen on :8080 and use NAT:

  iptables -t nat -I OUTPUT -p tcp -o lo --dport 80 -j REDIRECT --to-ports 8080

3. or make the port unprivileged

  sysctl -w net.ipv4.ip_unprivileged_port_start=80

It may work for httpd too, I haven't tested it.

The correct Systemd solution would be to create a socket unit but your solutions works without modifying the service code

I can't find anything for an officially supported for Apache or Nginx to support inetd/systemd socket activation bit it certainly would be nice.

I think this requires support from the service, no?

Not everything that wants to open up a port seems to support socket activation. I tried with 6tunnel and couldn't get it to work.

systemd provides a workaround in the form of systemd-socket-proxyd [1]. Granted it copies data, but when the max performance is not required, it works. Sometimes services allow to be configured to listen UNIX socket path, then systemd-socket-proxyd allows to disable ip address access by forwarding the network socket to that.

[1] https://www.freedesktop.org/software/systemd/man/systemd-soc...

Apache also uses the start user to read stuff like TLS private keys, that its normal user does not have access to.

It's possible to remove the root requirement for this through systemd's credentials mechanisms:

https://www.freedesktop.org/software/systemd/man/systemd.exe...

Which is the right way to have it link to a proper credential management system via tokens.

I seriously a few hours trying to find a way to do this and didn't once come across this mechanism, now that I've read it in still not sure how to use it. why is systemd so adverse to writing examples

I find this blogpost is a great example of code paired with systemd configuration for the certs:

https://mgdm.net/weblog/systemd/

And I think its common for the log files to be in /var/log/httpd owned by root but I suppose they could be moved and chown-ed.

Using systemd's LogDirectory= directive will fully take care of ensuring the required directory is present and permissions match the defined User=/Group= of the unit.

Some applications like nginx or php-fpm want to run worker processes under a different user account to isolate them from the main process. In those cases user namespaces are the best option. Too bad PrivateUsers= in systemd unit just does not cover this case.

These are workarounds and not good practices

It only needs to root to bind to privileged ports I believe. You should be able to use a non-root user and give it CAP_NET_BIND_SERVICE:

[Service]

AmbientCapabilities=CAP_NET_BIND_SERVICE

Cool! But then I suppose the forked processes could then bind to a low numbered port - something they can't do now. So Apache would have to make sure to revoke that capability when forking.

You could combine it with something like this

  SocketBindDeny=any
  SocketBindAllow=tcp:80
  SocketBindAllow=tcp:443

These ports should be denied by the kernel because they're already taken by httpd, and all other will be denied by bpf filters installed by systemd.

It feels like plugging holes in a dam, but that's what you do with popular operating systems.

hello.

i added support for httpd to support systemd socket activation in 2013: https://svn.apache.org/viewvc?view=revision&revision=1511033

httpd can start as non-root, assuming other configurations like the access / error logs are writable by the non-root user.

Many applications don't need to bind the port themselves but will happily accept one passed to them during process invocation.

This allows to let systemd to manage ports using socket units which will also stay up and buffer requests when restarting a service, allow service activation on demand/incoming requests or per connection service instances, e.g. for better isolation of sshd's per connection/user.

This is one of the main problems with "whole program sandboxes". Many times a program only needs permissions right at the start and then never again. From the outside though there's no way to signal "OK, I'm done, lock me down" for most sandboxing systems.

One approach that may work with systemd is to have two processes. One would be a broker, running as root. It would grab a port, for example. The other process would be spawned by the broker as a limited service and inherit that port from the parent, with no permissions of its own to open it, only to inherit.

IDK how to express that in systemd-land though. At that point you might be better off just writing the code to sandbox things yourself.

Reply on news.ycombinator.com