RE: -u option on CVS

[Daniel A. Deitch]

I was thinking along the same lines. Unfortunately, I know nothing about
perl, so I was at a loss ...

Here's the result of your suggestion:

spamass-milter[62772]: spamc gets jgarrison
spamd[61648]: connection from localhost [127.0.0.1] at port 1542 
spamd[61648]: handle_user: unable to find user 'sharedspam'! 
spamd[61648]: Still running as root: user not specified with -u, not
found, or set to root.  Fall back to nobody. 
spamd[61648]: processing message (unknown) for jgarrison:65534.

What if we put the if/then early in the script, maybe right after it
assigns the 'username' value  .... right below the GetOptions( ... Have
it compare the given 'username' value to an existing UID, then just
redefine it early in the script so that everything else just thinks that
sharedspam was the 'username' given by the milter?

Another thought on this is to stop trying to change the user. Can't I
just tell Spamassassin to use a different home directory as default. All
I really want out of this is to have the .spamassassin dir used for all
unknown users so that whitelist, blacklist and bayes can still be used
and effective.

Thanks again for ALL the help.

Daniel

________________________________

Daniel A. Deitch, President * iTrain Technologies, Ltd.
po box 13833 * atlanta, ga   30324-0833 * 404-876-1929 (o)
404-935-5005 (f) * www.goitrain.com 
 

-----Original Message-----
From: Dan Nelson [mailto:address@hidden 
Sent: Tuesday, February 08, 2005 12:14 AM
To: Daniel A. Deitch
Cc: address@hidden
Subject: Re: -u option on CVS

In the last episode (Feb 07), Daniel A. Deitch said:
> I went ahead and updated to 0.3.0 CVS just to see what would happen
> ... didn't fix the problem.

I wouldn't expect it to.  You were already running a relatively recent
CVS I think, so the only change is the version number :)

> I was looking through the logs again and saw the following which
> tells me that everything is working the way it's supposed to (I
> think). But I guess what I want to happen isn't in that range.
> 
> So, with multiple recipients, it falls to sharedspam. Now the
> question is, can I make it fall to sharedspam when there's only 1
> recipient that's all virtual?

After more rooting around in spamd sources, trying to figure out what
goes where, it looks like handle_user() does the setuid call, but the
returnvalue is never checked to see whether the username lookup worked
or not!  Only within handle_user() are config files read.  If the
username doesn't exist or the setuid call fails (the uid is verified
but the error code is ignored!), the function simply returns, and you
end up with system defaults from here on.  The code in check() is
solely a userid adjustment; no config file or username changes are
made.  The fact that perl apparently lets users assign values to $> and
$) to set the uid and gid doesn't make the code any clearer.

Try this (you can lose the first change I suggested as it doesn't do
anything useful for you):

--- spamd       Mon Jan 10 13:21:25 2005
+++ spamd.new   Mon Feb  7 23:07:58 2005
@@ -1375,6 +1375,13 @@ sub handle_user {
   my ( $name, $pwd, $uid, $gid, $quota, $comment, $gcos, $dir, $etc ) =
     getpwnam($userid);
 
+  if ( !defined($uid) ) {
+    $userid = "sharedspam";
+    $username = $userid;
+    my ( $name, $pwd, $uid, $gid, $quota, $comment, $gcos, $dir, $etc )
=
+      getpwnam($userid);
+  }
+
   if ( !$spamtest->{'paranoid'} && !defined($uid) ) {
 
     #if we are given a username, but can't look it up,



This is just above the code that reads in the userconfig files, so
hopefully it will set enough state that the rest of spamassassin uses
"sharedspam"'s config.

-- 
        Dan Nelson
        address@hidden