On Wed, 15 Feb 2006, Marc Haber wrote:
> The issue in question shows that some part in exim's content scanner
> invokes fopen() after explicitly setting umask(0), so that the file
> created ends up in the file system with 666 permission.
Near the start of Exim there is this code:
/* Set the umask to zero so that any files that Exim creates are created
with the modes that it specifies. */
umask(0);
The only other calls to umask are in connection with created
subprocesses (e.g. for the pipe transport). When Exim creates a spool
file, it does this:
/* Make sure the file's group is the Exim gid, and double-check the mode
because the group setting doesn't always get set automatically. */
(void)fchown(data_fd, exim_uid, exim_gid);
(void)fchmod(data_fd, SPOOL_MODE);
Although Exim is running as exim:exim at this point, I have a
recollection that in some filing systems / operating systems, the group
ownership may not work out right by default, so this code is making
absolutely sure.
> Is there a background to be considered why it was chosen to do things
> this way, should exim generally run with a more restrictive umask
> (only to be relaxed when it's really needed), or should a fopen()
> wrapper be used? Or am I misled in seeing a possible issue here?
Any background that there is happened far too long ago for me to
remember what it was. However, it is fairly obvious that Exim should not
just inherit whatever the umask happens to be when it is called.
My *guess* is that Tom didn't investigate umask properties when he
implemented the exiscan features. Perhaps the chown/chmod calls above
should be added to the content scanning fopen()s?
Tom?
--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book
