Date: Thu, 5 May 2005 21:09:10 +0400 From: Solar Designer <solar@...nwall.com> To: popa3d-users@...ts.openwall.com Subject: Re: popa3d logging under xinetd Sean, On Wed, May 04, 2005 at 09:29:10PM -0700, Sean Kelly wrote: > I've been hacking around in the popa3d code trying to figure out how it > works so that I might be able to get it to log/record the user's IP > address for use with pop-before-send SMTP access control. I just > discovered that the whole "channel" construct is pulling user session > data from a pipe rather than a socket as I was expecting when running > under xinetd. The "channel" stuff is being used to implement privilege separation. There is a socket, it is just not seen explicitly since it's provided by the *inetd. The socket is on fd 0/1/2 (stdin/out/err) at program startup. You can invoke getpeername(2) on any of these fd's to find out the remote client's IP address. The same would _also_ work when running standalone. Some software also sets the REMOTE_HOST environment variable. You can have your code fallback to uses of REMOTE_HOST when either the getpeername(2) call fails or the connection appears to come from localhost. This will let you do POP-before-SMTP even for SSL'ed connections with xinetd and stunnel. BTW, contrib/popa3d-0.6.2-whoson-1.diff.gz already implements just that, so you might not even need to develop the patch on your own. -- Alexander Peslyak <solar at openwall.com> GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598 http://www.openwall.com - bringing security into open computing environments Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.