You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2007/11/21 01:09:35 UTC
[Bug 5728] New: [review] spamd -q/--sql-config and --ldap-config do not disable setuid behaviour
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5728
Summary: [review] spamd -q/--sql-config and --ldap-config do not
disable setuid behaviour
Product: Spamassassin
Version: 3.2.3
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P5
Component: spamc/spamd
AssignedTo: dev@spamassassin.apache.org
ReportedBy: duncf@apache.org
When using spamd with -q/--sql-config or --ldap-config, spamd currently will try
to use the default setuid behaviour and setuid to the passed in user. This
doesn't really make sense. If we wanted the setuid behaviour, we'd use
-Q/--setuid-with-sql and/or --setuid-with-ldap.
Now, if we're not going to setuid, we should also require -u as we do with
vpopmail or virtual-config-dir. (That said, should we require -u or should we
only require -u if spamd is not run as root?)
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5728] [review] spamd -q/--sql-config and --ldap-config do not disable setuid behaviour
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5728
------- Additional Comments From duncf@apache.org 2007-11-20 16:19 -------
Sorry, I just realized that description is a little incorrect.
If we use --sql-config or --ldap-config, spamd won't try to use the default
setuid behavior, but it will try to fallback to nobody if it's running as root.
This doesn't really make sense, since we shouldn't be using the setuid behavior
to begin with.
Anyways, I've committed a patch. I'm still unsure whether we should drop the
requirement for '-u' if we're running spamd as a different (non-root) user.
Committed revision 596888.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5728] [review] require -u with --sql-config or --ldap-config
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5728
duncf@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
Summary|[review] spamd -q/--sql- |[review] require -u with --
|config and --ldap-config do |sql-config or --ldap-config
|not disable setuid behaviour|
------- Additional Comments From duncf@apache.org 2007-11-28 16:04 -------
Committed to 3.2 branch (with fixed typo in comment) as r599208
Updated Summary to reflect description better.
Filed bug 5734 in response to Justin's comments.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5728] [review] spamd -q/--sql-config and --ldap-config do not disable setuid behaviour
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5728
------- Additional Comments From jm@jmason.org 2007-11-23 01:51 -------
(In reply to comment #5)
> Now, does anyone have an opinion on whether we should be checking for -u or that
> $> != 0?
can you clarify?
what is the behaviour if run as non-root without -u? spamd won't be able to
setuid anyway so it should be a moot point...
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5728] [review] spamd -q/--sql-config and --ldap-config do not disable setuid behaviour
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5728
------- Additional Comments From duncf@apache.org 2007-11-27 18:57 -------
(In reply to comment #8)
> I think it's ok, since $setuid_to_user is set to 1 if ($> != 0).
I'm confused by your comment (what is ok?) -- what do you think is the right
thing to do?
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5728] [review] spamd -q/--sql-config and --ldap-config do not disable setuid behaviour
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5728
------- Additional Comments From duncf@apache.org 2007-11-27 13:57 -------
(In reply to comment #6)
> (In reply to comment #5)
> > Now, does anyone have an opinion on whether we should be checking for -u or that
> > $> != 0?
>
> can you clarify?
This whole section of code hurts my brain.
I believe under the current code, you can't run
"spamd --vpopmail" or "spamd --virtual-config-dir" as a non-root user. We
specifically check to see if these options are used without the "--username"
option and die.
With my change, this also applies to "spamd --sql-config" and "spamd --ldap-config".
The quick fix (I think) is to wrap this code (and the like)
if ( $opt{'vpopmail'} ) {
if ( !$opt{'username'} ) {
die "spamd: cannot use --vpopmail without -u\n";
}
}
with an "if ($setuid_to_user) {}" or "if ($> == 0) {}" block.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5728] [review] spamd -q/--sql-config and --ldap-config do not disable setuid behaviour
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5728
------- Additional Comments From duncf@apache.org 2007-11-20 16:25 -------
Created an attachment (id=4188)
--> (http://issues.apache.org/SpamAssassin/attachment.cgi?id=4188&action=view)
Fix for 3.2 branch
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5728] [review] spamd -q/--sql-config and --ldap-config do not disable setuid behaviour
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5728
------- Additional Comments From jm@jmason.org 2007-11-22 02:49 -------
+1
'sudo make test TEST_FILES=t/root*' passes.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5728] [review] spamd -q/--sql-config and --ldap-config do not disable setuid behaviour
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5728
------- Additional Comments From jm@jmason.org 2007-11-27 16:06 -------
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > Now, does anyone have an opinion on whether we should be checking for -u
or that
> > > $> != 0?
> >
> > can you clarify?
>
> This whole section of code hurts my brain.
>
> I believe under the current code, you can't run
> "spamd --vpopmail" or "spamd --virtual-config-dir" as a non-root user. We
> specifically check to see if these options are used without the "--username"
> option and die.
>
> With my change, this also applies to "spamd --sql-config" and "spamd
--ldap-config".
>
> The quick fix (I think) is to wrap this code (and the like)
>
> if ( $opt{'vpopmail'} ) {
> if ( !$opt{'username'} ) {
> die "spamd: cannot use --vpopmail without -u\n";
> }
> }
>
> with an "if ($setuid_to_user) {}" or "if ($> == 0) {}" block.
I think it's ok, since $setuid_to_user is set to 1 if ($> != 0).
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5728] [review] spamd -q/--sql-config and --ldap-config do not disable setuid behaviour
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5728
------- Additional Comments From jm@jmason.org 2007-11-28 03:02 -------
(In reply to comment #9)
> (In reply to comment #8)
>
> > I think it's ok, since $setuid_to_user is set to 1 if ($> != 0).
>
> I'm confused by your comment (what is ok?) -- what do you think is the right
> thing to do?
actually, ignore my comment -- I misread both your intentions, and the code ;)
So you said:
'I believe under the current code, you can't run
"spamd --vpopmail" or "spamd --virtual-config-dir" as a non-root user. We
specifically check to see if these options are used without the "--username"
option and die.
With my change, this also applies to "spamd --sql-config" and "spamd
--ldap-config".'
that's almost correct. Actually, it *IS* possible to run as non-root if the
user uses '-u $currentuser'; e.g. if you look at t/spamd_allow_user_rules.t, it
runs spamd with
spamd --virtual-config-dir=log/virtualconfig/%u -L -u $spamd_run_as_user
where $spamd_run_as_user is set by the test framework to be whatever the username
of the currently-running uid is. So the caller has to know what their current
username is, and use that in the invocation, and spamd will then run ok as
non-root with those options.
If you are suggesting that we should *automatically* deal with this case, by
doing something like
if ($> != 0 && !$opt{'username'}) {
# we are run as non-root; set username to whatever we're currently running as
$opt{'username'} = currently_running_username();
}
I would be in favour of this, as a new feature. But it'd be a separate bug...
is that what you were talking about?
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5728] [review] spamd -q/--sql-config and --ldap-config do not disable setuid behaviour
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5728
------- Additional Comments From parkerm@pobox.com 2007-11-21 10:59 -------
+1
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 5728] [review] spamd -q/--sql-config and --ldap-config do not disable setuid behaviour
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5728
------- Additional Comments From duncf@apache.org 2007-11-22 11:36 -------
Now, does anyone have an opinion on whether we should be checking for -u or that
$> != 0?
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.