http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5510
------- Additional Comments From [EMAIL PROTECTED] 2007-06-15 03:04 -------
(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.
