On Thu 2016-02-04 11:00:27 -0500, David Goulet wrote: > On 04 Feb (10:46:55), Daniel Kahn Gillmor wrote: >> On Thu 2016-02-04 07:40:39 -0500, David Goulet wrote: >> >> > I would like to know if adding support for Unix socket to sshd would be a >> > feature that would be consider to be added upstream? (ListenAddress). >> >> fwiw, i think this is a good idea, but i wouldn't implement it as an >> explicit ListenAddress option: i'd rather have sshd be able to listen on >> an inherited file descriptor. This would allow generic socket >> activation, regardless of socket type. > > Hrm... not sure I fully understand here. How would sshd inherited an fd? And > what do you mean by "allow generic socket activation"? If I understand it, > wouldn't that require a wrapper over sshd? > > Let's assume I set up an sshd and want it to use Unix socket in > /foo/bar/ssh.sock, how would that work without me being able to specify > somewhere the path? The most common toolchain for doing this sort of thing today on GNU/Linux systems is systemd, which acts as pid 1. systemd's pid 1 instance is configured to know which sockets will be listened for by all the daemons on the host, and it pre-opens all of those sockets. Then, when a connection is made to a socket that it knows should belong to a daemon, if that daemon isn't already running, it spawns (fork/execs) it, handing over the relevant socket(s) to the daemon as a file descriptor during startup. There are several advantages to this: * if the daemon can be run in a non-privileged mode, it can start in the non-privileged mode from the beginning. no need for each daemon to need to start privileged to grab the relevant socket and then drop privileges. we've seen many bugs around daemons not properly dropping privileges * no race for grabbing the socket. In the event that multiple daemons are want to listen on the same socket, there's a predictable arbiter (pid 1) who decides where the socket gets passed to, and other daemons that try to listen on that socket get rejected, because the socket is already busy. * before any daemons are running, the sockets are opened for incoming connections. This means there will be much smaller (possibly non-existent) window of time during system startup or daemon restart where the socket itself is closed. Connections made to these sockets before the associated daemon starts up will of course hang until the daemon gets around to responding, but the system won't reject the connections. * socket activation also enables the OS to selectively start services on an as-needed basis. If daemon X depends on daemon Y operationally (because X needs to talk to Y over Y's listening socket), there is no need for explicit representation of this startup dependency -- rather, the daemons are spawned as the first connections come in. Note that the daemon management service (what systemd's pid 1 provides) needs some way to communicate to the spawned daemon which file descriptors it has inherited should be treated as listeners. for systemd, this is a contiguious block of file descriptors starting at fd 3 (SD_LISTEN_FDS_START), and the enviornment variable LISTEN_FDS is a decimal number indicating how many file descriptors to use for listening (see sd_listen_fds(3) from libsystemd for more detail). A reasonable approach that would avoid linking in libsystemd might be to just specify something like ListenFDs N:M (meaning file descriptors N through M are sockets you should listen on). (perhaps -L N:M on the command line, so that the config file could stay static and the spawning daemon manager could dynamically adjust the invocation as sockets were added or removed) --dkg _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev