http://bugzilla.spamassassin.org/show_bug.cgi?id=3934
Summary: allow safe use of spamd on a multiuser machine using
UNIX domain sockets and setgid spamc
Product: Spamassassin
Version: 3.0.1
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P5
Component: spamc/spamd
AssignedTo: [email protected]
ReportedBy: [EMAIL PROTECTED]
dean gaudet <[EMAIL PROTECTED]>:
i wasn't ever fond of spamd trusting the User supplied by spamc -- and
while identd is an OK hack for folks who run spamd on a network, it seems
overkill for someone running spamd on localhost only. using unix domain
sockets there are two ways to increase the paranoia -- one would be to
pass credentials over the socket, the other is to use a setgid spamc and a
group-restricted unix domain socket. credential passing isn't easily
portable, so being lazy i've been using setgid spamc.
in my setup i have group spamc, and the socket is in /var/run/spamd, and i
set perms like so:
-r-xr-s--x 1 root spamc 22164 Oct 26 23:21 /usr/bin/spamc
drwxr-x--- 2 root spamc 4096 Oct 26 23:22 /var/run/spamd
srw-rw-rw- 1 root root 0 Oct 26 23:22 /var/run/spamd/sock
i stick the sock in a subdirectory which is group protected for historical
reasons ... it's more portable -- older unixen didn't respect unix domain
socket permissions... and prior to SA 3.0.0 i would have had to patch
spamd to get perms on the socket correct.
anyhow there's two more things to be done -- patch spamc to disable -u,
and make it default to this socket (so my users don't need to know these
details).
the patch i use is below, but i'd like to get something accepted upstream
so that i could eventually use a pre-built .deb rather than building my
own. the only part which needs generalizing is setting the default
transport ... i suppose a config file or shell wrapper would solve it.
(i don't like the shell wrapper because it messes with pre-packaged SA.)
suggestions?
-dean
--- spamassassin-3.0.1/spamc/spamc.c.orig 2004-10-22 18:39:18.000000000
-0700
+++ spamassassin-3.0.1/spamc/spamc.c 2004-10-27 11:53:58.000000000 -0700
@@ -277,6 +277,10 @@
}
case 'u':
{
+ if (getuid() && getgid() != getegid()) {
+ printf("you are running setgid, and -u is permitted only
when root\n");
+ ret = EX_USAGE;
+ }
*username = optarg;
break;
}
--- spamassassin-3.0.1/spamc/libspamc.c.orig 2004-10-22 18:39:18.000000000
-0700
+++ spamassassin-3.0.1/spamc/libspamc.c 2004-10-27 11:53:58.000000000 -0700
@@ -1124,8 +1124,13 @@
memset(tp, 0, sizeof *tp);
+#if 0
tp->type = TRANSPORT_LOCALHOST;
tp->port = 783;
+#else
+ tp->type = TRANSPORT_UNIX;
+ tp->socketpath = "/var/run/spamd/sock";
+#endif
tp->flags = 0;
}
later:
On Wed, 27 Oct 2004, Justin Mason wrote:
> Both will break existing usage at other sites; some thought for backwards
> compatibility is required before we could apply those to the distribution.
> In particular, defaulting to only allowing -u for root would break
> a *lot* of existing users running spamc from the MTA.
i think the setgid portion is backward compatible -- it only restricts -u
to root when the executable is installed setgid. otherwise it allows -u
just fine... i'm guessing very few folks use a setgid spamc, but let me
know.
as for the default transport -- i just figured out a local solution
that'll work with pre-packaged SA, so it's no biggie (which is good, i
didn't feel like writing config file parsing code :)
-dean
My opinion: this is cropping up on Red Hat's bugzilla as well, at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136367 . Well worth
fixing. I think dean's point is worthwhile -- the -u restriction only takes
effect if spamc is setgid, and it will never be setgid unless something like
this is what the developer had in mind, anyway. so this may be a good
solution...
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
