![]() ![]() |
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:
[uid new_uid, stat filemode, mode wantmode ] If access is finally allowed, sendmail concludes with: OK Otherwise, it concludes with: EACCES |
![]() ![]() |