Bug 1604 - spamd does not setgid
Summary: spamd does not setgid
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamc/spamd (show other bugs)
Version: 2.50
Hardware: Other other
: P5 normal
Target Milestone: 2.50
Assignee: Malte S. Stretz
URL: http://bugs.debian.org/cgi-bin/bugrep...
Whiteboard:
Keywords: backport
Depends on:
Blocks:
 
Reported: 2003-03-04 20:40 UTC by Duncan Findlay
Modified: 2003-03-13 10:24 UTC (History)
1 user (show)


Attachment Type Modified Status Actions Submitter/CLA Status
suggested patch patch None Theo Van Dinter [HasCLA]
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 Duncan Findlay 2003-03-04 20:40:55 UTC 
From: Nathan Poznick <poznick@conwaycorp.net>

Package: spamassassin
Version: 2.50-1
Severity: wishlist
Tags: sid upstream

spamd does not do a setgid() along with its setuid().  This shows up
(for me at least) when running spamd globally without the -u username
option, but since there is not a corresponding -g groupname option, I
would assume that the same problem appears when using -u.  This means
that files which are created by spamd when it runs (such as the new
Bayesian classification db files), get created as owned by the user
running spamc, but by whatever group spamd was originally running as
(root, in the case of starting spamd from /etc/init.d/spamassassin).

I'm tagging this as a wishlist item, since the communication
between spamc and spamd does not appear contain the group information,
so it will likely require an upstream development effort to resolve
this.

In short, it's my opinion (possibly wrong), that:
1) spamd should get a -g group option to go along with its existing -u
user option.
2) the communication between spamc and spamd should be enhanced to
include the group of the user, or spamd should look up the group of the
user. (the --auth-ident option would need consideration as well).

Thanks,
Nathan

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux tao 2.4.20 #1 Thu Jan 30 00:00:04 CST 2003 i686
Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set)

Versions of packages spamassassin depends on:
ii  debconf                       1.2.29     Debian configuration management sy
ii  libhtml-parser-perl           3.26-0.1   A collection of modules that parse
ii  perl                          5.8.0-17   Larry Wall's Practical Extraction 
ii  spamc                         2.50-1     Client for perl-based spam filteri

-- debconf information:
  spamassassin/upgrade/2.40: 
  spamassassin/upgrade/cancel: Continue
* spamassassin/upgrade/2.42: No
Comment 1 Theo Van Dinter 2003-03-05 10:13:28 UTC 
I think it makes sense to do this, so I'll reassign to myself and poke about.
Comment 2 Theo Van Dinter 2003-03-05 10:50:46 UTC 
Created attachment 722 [details]
suggested patch
Comment 3 Theo Van Dinter 2003-03-05 10:51:22 UTC 
Anyone care to comment? :)
Comment 4 Malte S. Stretz 2003-03-05 13:05:35 UTC 
Looks good. BUT (sorry ;-)... 
 
| $)  The effective gid of this process.  *If you are on 
| a machine that supports membership in multiple 
| groups simultaneously*, gives a space separated 
| list of groups you are in.  The first number is 
| the one returned by getegid(), and the subsequent 
| ones by getgroups(), one of which may be the same 
| as the first number. 
|  
| Similarly, a value assigned to $) *must* also be a 
| space-separated list of numbers. [...] 
 
I don't like the "if it is supported" vs. the "must". Do anybody know any 
system where this isn't supported?
Comment 5 Theo Van Dinter 2003-03-05 13:40:47 UTC 
Subject: Re: [SAdev]  spamd does not setgid

On Wed, Mar 05, 2003 at 01:05:35PM -0800, bugzilla-daemon@hughes-family.org wrote:
> Looks good. BUT (sorry ;-)... 

:)

> | $)  The effective gid of this process.  *If you are on 
> | a machine that supports membership in multiple 
> | groups simultaneously*, gives a space separated 
> | list of groups you are in.  The first number is 
> | the one returned by getegid(), and the subsequent 
> | ones by getgroups(), one of which may be the same 
> | as the first number. 
> |  
> | Similarly, a value assigned to $) *must* also be a 
> | space-separated list of numbers. [...] 
>  
> I don't like the "if it is supported" vs. the "must". Do anybody know any 
> system where this isn't supported? 

Windows maybe (don't do a lot of programming there), but I'm not sure if I
understand what your issue is anyway.  Basically it's saying that reading
$) will result in either a single number or a space-seperated list of
numbers, and if you want to set it, you need to give it at least 2 numbers
seperated by a space (ie: the egid and the list to send to setgroups()).

So the new code does '$) = "$gid $gid"'.  On platforms with multiple
groups, perl will call setgroups($gid).  On platforms which don't support
multiple groups, perl will just ignore the second number.  We don't need
to worry about the platform we're on.

Technically, we should probably look up the list of groups that are valid
and pass that instead of just the primary gid twice.  I think that's going to
be computationally expensive to do per message, but...
Comment 6 Malte S. Stretz 2003-03-05 13:54:54 UTC 
Oh. I misinterpreted the manpage a bit. I think this is my week of stupid 
questions; too much Windows at work might be the reason ;-)  
 
OKAY: using the wrong group is a bug IMHO
Comment 7 Theo Van Dinter 2003-03-13 19:24:10 UTC 
committed to 2.5 branch.  closing bug.