http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5518
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P5 |P1
------- Additional Comments From [EMAIL PROTECTED] 2007-06-15 05:19 -------
for reference, comments 9 to 13 from bug 5510:
------- Additional Comment #9 From Sidney Markowitz 2007-06-14 18:37 [reply]
-------
This doesn't work for me in MacOS 10.4.9, but the bug may be something in spamd
that I didn't notice before. This error happens when you try as root to run
spamd --virtual-config-dir=somepath -u nobody
which is what t/spamd_allow_user_rules.t tries to do
[16061] info: spamd: server started on port 48825/tcp (running version
3.2.2-r547235)
[16061] info: spamd: server pid: 16061
[16061] info: spamd: server successfully spawned child process, pid 16065
[16061] dbg: prefork: child 16065: entering state 0
[16061] dbg: prefork: new lowest idle kid: none
[16061] info: spamd: server successfully spawned child process, pid 16066
[16061] dbg: prefork: child 16066: entering state 0
[16061] dbg: prefork: new lowest idle kid: none
[16065] error: setrgid() not implemented at ../spamd/spamd.raw line 1041.
setrgid() not implemented at ../spamd/spamd.raw line 1041.
[16066] error: setrgid() not implemented at ../spamd/spamd.raw line 1041.
setrgid() not implemented at ../spamd/spamd.raw line 1041.
[16061] dbg: prefork: child closed connection
------- Additional Comment #10 From Sidney Markowitz 2007-06-14 19:38 [reply]
-------
Doing some digging I fond this mentioned as a long-time problem with trying to
run spamd as nobody on MacOS X. Both the uid and gid of 'nobody' on the Mac are
-2 and that seems to confuse things as the spamd sees $ugid as having a value of
4294967294 and then $( = $ugid produces the misleading error message that
setrgid is not implemented.
spamd --virtual-config-dir=somepath -u www
for example executes the $( = $ugid; with no error.
------- Additional Comment #11 From Sidney Markowitz 2007-06-14 19:49 [reply]
-------
getpwnam('nobody') returns the 4294967294 values instead of -2. If at that point
I force the values of $uuid and $ugid to be -2 then everything seems to work
correctly.
I see some code that appears to recognize the possibility of something like this
if ( $> != $uuid and $> != ( $uuid - 2**32 ) ) {
die "spamd: setuid to uid $uuid failed\n";
}
but I don't really know what is going on with the various tests and workarounds
for BSD-specific behavior so I don't know just how to fix this.
------- Additional Comment #12 From Sidney Markowitz 2007-06-14 21:13 [reply]
-------
More digging: The underlying variables in the C library are unsigned ints. So
getpwnam returns what is there which looks like 4294967294 even though Apple
puts a -2 in /etc/passwd. Assignments to $< and $> are fine with either
4294967294 or -2, doing the same thing in either case. It is only assignments to
$( and $) that flake out if the number is bigger than the maximum positive 32
bit signed int.
However, POSIX::setgid() works fine to set both the real and effective gid with
one call and it accepts 4294967294.
So I suggest that we replace
$) = "$ugid $ugid"; # effective gid
$( = $ugid; # real gid
with
setgid($ugid);
I'm not expert in this stuff... Does anyone see any problem with using
POSIX::setgid here on other platforms?
------- Additional Comment #13 From Justin Mason 2007-06-15 03:04 [reply]
-------
(In reply to comment #12)
> More digging: The underlying variables in the C library are unsigned ints. So
> getpwnam returns what is there which looks like 4294967294 even though Apple
> puts a -2 in /etc/passwd. Assignments to $< and $> are fine with either
> 4294967294 or -2, doing the same thing in either case. It is only assignments
> to
> $( and $) that flake out if the number is bigger than the maximum positive 32
> bit signed int.
this sounds like a perl bug on MacOS X (another one!! what are they doing over
there?)
> However, POSIX::setgid() works fine to set both the real and effective gid
> with
> one call and it accepts 4294967294.
>
> So I suggest that we replace
>
> $) = "$ugid $ugid"; # effective gid
> $( = $ugid; # real gid
>
> with
> setgid($ugid);
>
> I'm not expert in this stuff... Does anyone see any problem with using
> POSIX::setgid here on other platforms?
it may not be implemented, for one, which would cause a die(). We'd have
to protect it with an eval ' ... ' block.
you'd probably have to do sth like this:
- run the $) / $( assignments in an eval '...' block
- capture errors
- if error =~ /setrgid\(\) not implemented/, then
- run POSIX::setgid(...)
- die if that failed too
however would it be simpler to just do (pseudocode)
if (platform eq MacOS && ($uid = getpwnam($user)) == 4294967294) { $uid = -2;
}
if that works, that would be better than attempting to use another syscall
entirely, IMO.
Also I suggest that should be opened as a totally separate bug; it's not caused
by this one, it's just being _exposed_ by the fix.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
