Bug 4109 - spamc/spamd don't provide authentication via PF_UNIX sockets
Summary: spamc/spamd don't provide authentication via PF_UNIX sockets
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Libraries (show other bugs)
Version: 3.0.2
Hardware: Other other
: P5 enhancement
Target Milestone: Future
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-01-27 13:52 UTC by Enrik Berkhan
Modified: 2010-04-21 20:18 UTC (History)
0 users



Attachment Type Modified Status Actions Submitter/CLA Status
Patch enabling the features mentioned in the original report. patch None Enrik Berkhan [NoCLA]
Patch for 3.0.3 patch None Enrik Berkhan [NoCLA]

Note You need to log in before you can comment on or make changes to this bug.
Description Enrik Berkhan 2005-01-27 13:52:20 UTC
spamc/spamd allow for user authentication via RFC1413 ident within a trusted
cluster. There is currently no similar mechanism for local access via PF_UNIX
sockets.

Many UN*X-like OSs have mechanisms to identify the user connecting via PF_UNIX
socket. I've written a small patch for spamd that enables authentication via
sockopt(SO_PEERCRED) (see attachment). The patch mixes the SO_PEERCRED stuff
with another enhancement: --trusted-user <username> allows to specify a trusted
user that is permitted to set any other userid via spamd's User: header iff he
can be identified correctly before. Sorry for mixing the two, but it's still
small enough to understand, I think ;-)

The benefits from the two patches for me are

1) allows to run spamc from e.g. exim under its own trusted user id while
allowing to use -u ${local_part} to get individual user prefs and still use
--auth-ident
2) allows to run 1) without tcp/ident overhead when used locally
Comment 1 Enrik Berkhan 2005-01-27 13:55:54 UTC
Created attachment 2631 [details]
Patch enabling the features mentioned in the original report.

Currently, the code is linux-specific wrt SO_PEERCRED. Note especially the
"struct ucred" unpacking. This is most probably not implemented portably.

There exist other mechanisms for PF_UNIX identification, e.g. for Solaris,
IIRC.
Comment 2 Enrik Berkhan 2005-06-08 04:01:35 UTC
Created attachment 2929 [details]
Patch for 3.0.3

Same patch as before for 3.0.3
Comment 3 Justin Mason 2006-12-05 06:44:50 UTC
unlikely to happen in 3.2.0, due to the unportability
Comment 4 Justin Mason 2006-12-12 12:40:22 UTC
moving RFEs and low-priority stuff to 3.3.0 target
Comment 5 Justin Mason 2010-01-27 02:20:35 UTC
moving most remaining 3.3.0 bugs to 3.3.1 milestone
Comment 6 Justin Mason 2010-01-27 03:16:23 UTC
reassigning, too
Comment 7 Justin Mason 2010-03-23 16:33:36 UTC
moving all open 3.3.1 bugs to 3.3.2
Comment 8 Karsten Bräckelmann 2010-03-23 17:42:42 UTC
Moving back off of Security, which got changed by accident during the mass Target Milestone move.