Exim very clearly documents that "hide" should prefix any options which
are insecure. How hard can it be to see if the generated configuartion
file contains *any* hide directives?
If you are worried about providing a false sense of security, then you
could always just print a notice (don't even worry about trying to
interpret the contents of the config files) that CFILEMODE is world
readable when that is the case:
/etc/init.d/exim4 reload
Reloading exim4 configuration files, notice:
/var/lib/exim4/config.autogenerated produced with permissions 644.
That will be enough of a clue to someone familiar with exim, but NOT
familiar with the behind-the-scenes stuff going on in this particular
implementation, that they may not be done.
The problem as I see it is that a false sense of security is being
provided by the fact that it is not obvious that there is another
configuration file produced based on the files in /etc/exim4/conf.d and
the fact that other exim environments use the split-files idea, but not
the two stage configuration (and the people editing those files assume
that they *are* the files, and *their* permissions are the ones which
apply).
I'm proposing a warning specifically to catch those who have no idea
that they may have an insecure config file, not to reassure those who
are expecting the absence of a warning to automatically believe that
that absence means its secure. (I can write an incorrect program that
passes a compiler with flying colors, does that mean that compiler
warnings and errors are useless and should be done away with?)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
