Re: SSL and systemd

On Thu, 14 Sep 2017, Andrew Daviel wrote:

>
> I have panda-imap running on CentOS 7 with xinetd.
> We wanted to implement it using a systemd service instead, so I made files
> /usr/lib/systemd/system/[email protected] imaps.socket imap.socket [email protected]
>
> The server appears to work on port 143 with STARTTLS (or notls)
>
> But on port 993 it responds with plaintext.
>
> If I enable DEBUG logging in syslog, with xinetd I get messages like
> Login user=andrew host=blah.example.com [192.168.2.3]
> imaps SSL service init from 192.168.2.3
> but with systemd service I get
> Login user=andrew host=[NON-IPv4]
> Line too long before authentication host=[NON-IPv4]
>
> I suspect some code in server_init in osdep/unix/env_unix.c
> which I don't entirely understand
>
>
> Has anyone solved this ?

I'm not familiar with how systemd sockets presents the client session 
connections to the servers it runs.

panda/UW imapd assumes that it can get connection network address info out of 
the thing bound to the standard-in file-descriptor (FD == 0) (using things like 
the getpeername & getsockname c-lib calls). (look in tcp_unix.c, 
tcp_serveraddr).
Once it has that info it does a series of machinations to determine if the port 
number used in the server side of the connection should be considered a 
classical SSL port (EG 993, etc).
If so it does the classical SSL session initiation (with ssl_open).

Evidently those getpeername & getsockname c-lib calls don't work in a systemd 
session environment. (resulting in those "host=[NON-IPv4]" log entries).

What you're seeing is the result of the client trying to do a SSL session to a 
server that hasn't done a ssl_open and thus isn't ready for the SSL stuff.

So what's needful is for somebody to figure out how to do the functional 
equivalent of getpeername & getsockname in a systemd environment.