The V8 sendmail program tries to be extra careful about file permissions, and the key to checking them is the internal safefile( ) function. The -d44.4 debugging switch^[4] prints the parameters passed to the safefile( ) function:

^[4] There is no -d44.1 debugging information.

safefile(fname, uid=user-id, gid=group -id, flags=sff_flags, mode=wantmode) 

Here, the file named fname is being checked to determine whether the user identified by the user-id, with the group group-id, is allowed to find or use the file. The range of checking is determined by the hexadecimal sff_flags, described in Table 16-12. Where a file's permissions are required, the mode printed in wantmode will be used.

If both the SFF_NOPATHCHECK flag and SFF_SAFEDIRPATH flags are clear (are 0), sendmail examines each component of the path leading to the file. If any component of the path is rejected, the -d44.4 debugging switch causes sendmail to print:

[dir fname]  reason for the rejection here 

A path component can fail because stat(2) failed. If the user-id is 0 for root, a warning is logged if a component is found to be group- or world-writable. For example:

hash map "Alias0": unsafe map file /etc/mail/aliases.db: World-writable directory

For each component in the path, safefile( ) checks to verify that this user has permission to search the directory. If the SFF_ROOTOK flag is not set (is clear), root (user-id 0) access is special-cased in that all directory components must be world-searchable.

Otherwise, the path component is accepted if it is owned by the user-id and has the user search bit set, or if its group is the same as group-id and has the group search bit set. If NO_GROUP_SET is undefined when sendmail is compiled (NO_GROUP_SET) and the DontInitGroups option (DontInitGroups) is not set, each group to which user-id belongs is also checked. Otherwise, the directory must be world-searchable.

If the fname could not be checked with stat(2), the -d44.4 debugging switch causes the reason to be printed:

 reason for failure here

If the file does not exist, it might need to be created. If so, sendmail checks to be sure that the user-id has write permission. The result is printed with the -d44.4 debugging switch like this:

[final dir fname uid user-id mode wantmode ]  error  here 

If the file exists and if symbolic links are supported, the file is rejected if it is a symbolic link and if the SFF_NOSLINK flag is set. If the -d44.4 debugging switch is specified, this error is printed:

[slink mode mode]    EPERM

If the SFF_REGONLY flag is set the file must be a regular file. If it is not, it is rejected, and -d44.4 causes the following to be printed:

[non-reg mode mode]    EPERM

If wantmode has the write bits set, and the existing file has any execute bits set, the file is rejected and -d44.4 causes the following to be printed:

[exec bits mode]    EPERM

If the file has more than one link, the file is rejected and -d44.4 causes the following to be printed:

[link count nlinks]    EPERM

If the SFF_SETUIDOK flag is specified, if SUID_ROOT_FILES_OK (SUID_ROOT_FILES_OK) was defined when sendmail was compiled,^[5] if the file exists, if it has the set-user-id bit set in the mode but no execute bits set in the mode, and if it is not owned by root, sendmail performs subsequent checks under the set-user-id and set-group-id identities of the existing file. A similar process occurs with the set-group-id bit. Sendmail then prints:

^[5] Note that set-user-id root files are permitted if sendmail was compiled with SUID_ROOT_FILES_OK defined, but we highly recommend against that definition.

[uid new_uid, stat filemode, mode wantmode ] 

If access is finally allowed, sendmail concludes with:

OK

Otherwise, it concludes with:

EACCES