Thanks for the insights. However, I am optimistic that for smtp sessions this can be made to (mostly) work, because the check for UID of the process holding the client port can be done some time after SMTP commands have been received by Postfix, at which point the connection is already established.
On CentOS there is "authd" daemon that implements IDENT protocol. When queried with port pair, it supposedly provides UID of the process holding the client port: https://github.com/InfrastructureServices/authd I haven't found any mention suggesting authd is not reliable (except for some bugs on Redhat bugzilla which got solved). Do you think it is not reliable, when the query is made after the TCP connection is established and Postfix has received the RCPT TO command? Back to my project, I think I can get this working by running a policy daemon as described in http://www.postfix.org/SMTPD_POLICY_README.html , only instead of handling greylisting, the daemon will query the authd daemon with port pair, get UID and then determine action for Postfix based on settings/reputation of that UID. I will try this later and report back. If this works, the next question would be, is it possible to pass the UID to Postfix as well and use that UID in Postfix config to alter its behaviour when processing the email? For example, the UID should be logged next to email ID to /var/log/maillog. S pozdravem Ján Lalinský Webhosting C4 ČESKÝ WEBHOSTING s.r.o. Tel: +420 234 139 876 E-mail: i...@c4.cz http://www.c4.cz On 13/11/2019 00:34, Viktor Dukhovni wrote: > On Tue, Nov 12, 2019 at 05:13:05PM -0500, Viktor Dukhovni wrote: > >>> To achieve this, I'd like to set up Postfix+Linux -based outgoing mail >>> server, possibly with some helper daemon. Any incoming TCP connection on >>> localhost:25 where Postfix listens will be handled in a way dependent on >>> the UID of the process that initiated it. In short, I want to police the >>> emails based not on the sender email address or IP address, but based on >>> the sender UNIX UID. >> The bad news is that on a multi-processing Linux system it is >> not possible to reliably determine the UID at the other end of >> a loopback TCP connection. The data in /proc/net/tcp or >> exposed via AF_NETLINK lacks the read/write barriers required >> to ensure that the client pid/uid are visible on the server's >> CPU at the time that the server accepts the client's connection. > I should perhaps note that my colleagues and I have seen problems > determining the peer uid (in an HTTP proxy) when the client is > Firefox, and not when the client is curl or multi-threaded C-code > that tried to "emulate" Firefox. So one could perhaps be "lucky" > with the particular mix of clients one needs to support, but... > > Even one is able to extract peer uid data for loopback TCP sockets > on Linux (via AF_NETLINK sockets, and/or parsing /proc/net/tcp). > That's rather platform-specific code, that won't work beyond Linux, > and I don't see this as a likely Postfix feature at present. >
