Overriding File Security Checks
Beginning with version 8.9.0, sendmail has tightened the rules
used for opening files. Sendmail now checks the modes and ownership
of the files and the directory path leading up to that file to
prevent users from taking advantage of overly permissive modes on
directories and files.
During your migration to sendmail 8.9, you will need to fix up
any permissions which would be considered unsafe such as non-root
owned directories containing maps or group writable directories and
files. In general, directories which sendmail reads from should be
owned by root unless the
RunAsUser option is set.
There are exceptions to this rule such as user
You may have to tweak your environment to make it safer for
sendmail to run. If you find that some of the safeties in sendmail
are too restrictive for your environment, they can be turned off by
setting the option
DontBlameSendmail. The option is
appropriately named as sendmail is not to be blamed for problems
resulting from unsafe permissions on directories and files.
Checking your system for these unsafe files is simply a matter
of performing a few commands to see if they report any problems.
For example, if rebuilding the aliases file with:
# newaliases -v
gives messages such as:
WARNING: writable directory /etc
WARNING: writable directory /usr/spool/mqueue
then the directories listed have inappropriate write permissions
and should be secured to avoid various possible security attacks.
Although somewhat verbose, a good test to make sure sendmail is
satisfied with the permissions on your database maps, class files,
and aliases file is the command:
# sendmail -v -d44.4 -bv
This will output the file safety checks as they are done and the
results of each one.
The biggest surprise is likely to come from
:include: files in unsafe
directory paths (directory paths which are group or world
writable). This is no longer allowed. This would mean that if user
joe's home directory was writable by group staff, sendmail would
not use his
.forward file. This behavior can be
altered, at the possible expense of system security, by setting the
DontBlameSendmail option. For example, to allow
forward files in group writable directories:
Or to allow them in both group and world writable
Items from these unsafe
:include: files will be marked as unsafe addresses --
the items can not be deliveries to files or programs. This behavior
can also be altered via
The first flag allows the forward file to be read, the second
allows the items in the file to be marked as safe for file and
Other files affected by this strengthened security include class
Fw /etc/sendmail.cw), persistent host
status files, and the files specified by the
HelpFile options. Similar
DontBlameSendmail flags are available for these
DontBlameSendmail option takes one or more
names that disable checks. In the descriptions that follow,
"unsafe directory" means a directory that is writable by
anyone other than the owner. The values are:
||No special handling.
||Assume that the
chown system call is restricted to
root. Since some versions of UNIX permit regular users to give away
their files to other users on some filesystems,
sendmail often cannot assume that a given file was
created by the owner, particularly when it is in a writable
directory. You can set this flag if you know that file giveaway is
restricted on your system.
||When reading class files (using the
F line in the
configuration file), allow files that are in unsafe
||Prevent logging of unsafe directory path warnings for
non-existent forward files.
||Allow the file named in the
ErrorHeader option to
be in an unsafe directory.
||Allow delivery to files that are hard links.
||Allow delivery to files that are symbolic links.
||Allow .forward files in group writable directories.
||Allow .forward files in unsafe directories.
||Allow a .forward file that is in an unsafe directory to include
references to program and files.
||Accept a group-readable key file for STARTTLS.
||Accept a group-readable Cyrus SASL password file.
||Allow group-writable alias files.
||Change the definition of "unsafe directory" to
consider group-writable directories to be safe. World-writable
directories are always unsafe.
||Allow group writable .forward files.
||Allow group wriable :include: files.
||Accept a group-writable Cyrus SASL password file.
||Allow the file named in the
HelpFile option to be
in an unsafe directory.
:include: files in group writable
:include: files in unsafe directories.
:include: file that is in an unsafe
directory to include references to program and files.
||Try to use STARTTLS even if the PRNG for OpenSSL is not
properly seeded despite the security problems.
||Allow an alias file that is a link in a writable
||Allow class files that are links in writable directories.
.forward files that are links in writable
:include: files that are links in writable
||Allow map files that are links in writable directories.
||Allow the service switch file to be a link even if the
directory is writable.
||Allow maps (e.g.,
dbm files) in unsafe directories.
||Do not mark file and program deliveries as unsafe if sendmail
is not running with root privileges.
||Go ahead and run programs that are in writable
||Go ahead and run programs that are group- or
||Allow group or world writable directories if the sticky bit is
set on the directory. Do not set this on systems which do not honor
the sticky bit on directories.
||Accept world-writable alias files.
||Allow world writable .forward files.
||Allow world wriable :include: files.
||Allow writes to maps that are hard links.
||Allow writes to maps that are symbolic links.
||Allow the status file to be a hard link.
||Allow the status file to be a symbolic link.