'-d44.4'' ''''

-d44.4

Trace safefile( ) Debug command-line switch

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.

Table 16-12. safefile( ) access flags

Mnemonic

Hex flag

Description

SFF_ANYFILE

0x00000000

No special restrictions

SFF_MUSTOWN

0x00000001

User must own this file

SFF_NOSLINK

0x00000002

File cannot be a symbolic link

SFF_ROOTOK

0x00000004

OK for root to own this file

SFF_RUNASREALUID

0x00000008

If no controlling user, run as real user-id

SFF_NOPATHCHECK

0x00000010

Don't bother checking directory path

SFF_SETUIDOK

0x00000020

Set-user-id files are OK

SFF_CREAT

0x00000040

OK to create file if necessary

SFF_REGONLY

0x00000080

Regular files only

SFF_SAFEDIRPATH

0x00000100

No writable directories (also check owner)

SFF_NOHLINK

0x00000200

File cannot have hard links

SFF_NOWLINK

0x00000400

Links only in nonwritable directories

SFF_NOGWFILES

0x00000800

Disallow group-writable files

SFF_NOWWFILES

0x00001000

Disallow world-writable files

SFF_OPENASROOT

0x00002000

Open as root instead of real user

SFF_NOLOCK

0x00004000

Don't lock the file

SFF_NOGRFILES

0x00008000

Disallow group-readable files

SFF_NOWRFILES

0x00010000

Disallow world-readable files

SFF_NOTEXCL

0x00020000

Creates don't need to be exclusive

SFF_EXECOK

0x00040000

Executable files are OK

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


    Part I: Build and Install
    Part II: Administration
    Part III: The Configuration File