Hi,
While trying to debug/test my AMaViS-ng's system filter+embedded Perl
setup, I have run across a few strange things:
All the Perl code is called from the system filter, and it is run from
the Exim user (which on Debian is mail(8)). I was testing with
$ mail bengen < $file.
If I set perl_at_start to "false", Perl tells me that it is running as
UID=root,EUID=mail. This seems OK to me: In normal operation (no
"security" option set), can drop its EUID to the mail user, run the
system filter (and my script), and return to its previous state.
However, if I set perl_at_start to "false", I am told that the code is
running as UID=root,EUID=root. But all the files that are generated
(during digesting the messages) are owned by mail.
Does Perl cache the results from getuid, geteuid for its $<, $>
variables in memory, only to modify or invalidate them on certain
system calls? Or is there another explanation for this strange
behavior?
-Hilko
While trying to debug/test my AMaViS-ng's system filter+embedded Perl
setup, I have run across a few strange things:
All the Perl code is called from the system filter, and it is run from
the Exim user (which on Debian is mail(8)). I was testing with
$ mail bengen < $file.
If I set perl_at_start to "false", Perl tells me that it is running as
UID=root,EUID=mail. This seems OK to me: In normal operation (no
"security" option set), can drop its EUID to the mail user, run the
system filter (and my script), and return to its previous state.
However, if I set perl_at_start to "false", I am told that the code is
running as UID=root,EUID=root. But all the files that are generated
(during digesting the messages) are owned by mail.
Does Perl cache the results from getuid, geteuid for its $<, $>
variables in memory, only to modify or invalidate them on certain
system calls? Or is there another explanation for this strange
behavior?
-Hilko