Inheriting capabilities

Posted Feb 12, 2015 11:22 UTC (Thu) by ibukanov (subscriber, #3942)
In reply to: Inheriting capabilities by Cyberax
Parent article: Inheriting capabilities

I wonder why most server-like programs still insist on binding the socket themselves rather than either accepting the socket on stdin or from an external proxy wrapper. It solves CAP_NET_BIND problems and gives administrator more flexibility with socket configuration.

Inheriting capabilities

Posted Feb 12, 2015 12:08 UTC (Thu) by vonbrand (subscriber, #4458) [Link] (2 responses)

<cough>systemd</cough>

Inheriting capabilities

Posted Feb 12, 2015 12:34 UTC (Thu) by ibukanov (subscriber, #3942) [Link] (1 responses)

Using systemd for socket initialization with services that opens more then one port or those that cannot be lazily initialized requires to use systemd-specific API and still does not allow to bind low ports for user processes unless one uses the system instance of systemd.

Instead it would be better if services allow to specify an external command that returns the bound socket so one can use whatever mechanism to bind the port like dynamic port numbers etc. and integration with systemd becomes trivial.

Inheriting capabilities

Posted Feb 12, 2015 14:15 UTC (Thu) by fishface60 (subscriber, #88700) [Link]

ssh lets you do something like this for connecting to unusual targets with the ProxyCommand option when combined with ProxyUseFdpass.

By default ProxyCommand requires the process to proxy the messages between stdin and stdout, but if you set ProxyUseFdpass, the proxy command is passed a socket pair instead, and should send a file descriptor over its stdout. So rather than having your proxy command needing to constantly process data, it can pass the connection back to ssh.

I'd guess the reason why more services don't let you do stuff like this is that it's awkward to do in C, and the networking abstractions in most of the programming languages I use don't support it.

Inheriting capabilities

Posted Feb 12, 2015 14:00 UTC (Thu) by fishface60 (subscriber, #88700) [Link]

Indeed, I've often had reason to start a service on a non-fixed-port, and ephemeral ports are a better solution than launching the service on a random port in a loop until it finds one successfully.

I usually end up with a wrapper program that binds to an ephemeral port and writes out which port was chosen to a named pipe before launching the program in inetd mode.

Inheriting capabilities

Posted Feb 12, 2015 18:35 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Lots of services expect the interface and port to be configured in the configuration file. Moving it to a helper process would require having some sort of "external" configuration which might not be appropriate for existing tools.