Bug 3926 - spamd now setuid()ing before creating spamd pidfile
Summary: spamd now setuid()ing before creating spamd pidfile
Status: RESOLVED DUPLICATE of bug 3577
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamc/spamd (show other bugs)
Version: 3.0.1
Hardware: Sun Solaris
: P5 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on: 3577
Blocks:
  Show dependency tree
 
Reported: 2004-10-26 00:47 UTC by Bruno Connelly
Modified: 2004-11-05 08:34 UTC (History)
0 users


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Bruno Connelly 2004-10-26 00:47:14 UTC 
When passing the -r argument to spamd to log the PID to disk, spamd seems to now
setuid() to the user specified by the -u argument _first_.  This kills the
ability to log the PID to somewhere like /var/run/ prior to dropping privileges.

This behavior seems to exist in the spamd packaged with both SpamAssassin 3.0.0
and 3.0.1, but the 2.6.x releases did not exhibit this.  Is this intentional, or
an oversight?

It looks like bug3577 suggests switching to a model where the spamd parent
maintains root privs and only having children setuid(), which would make this
bug a moot point.
Comment 1 Theo Van Dinter 2004-11-05 17:34:05 UTC 

*** This bug has been marked as a duplicate of 3577 ***