Verifying that the sticky bit is on

If the daemon module resides in an MVS™ load library, the file containing the daemon module must have the sticky bit set on. For information about how to verify that the sticky bit is on, see Table 1.

Table 1. Verifying that the sticky bit is on. This table summarizes how to verify that the sticky bit is on in certain situations.
If you are using this. . .	Then . . .
The ISPF shell	From the ISPF shell, enter the file name of the daemon (/usr/sbin/daemon1, for example) and request Attributes. Result: You will see a display similar to the following: `Display File Attributes Pathname : /usr/sbin/daemon1 Link count . . . . : 2 Set UID bit . . . : 0 Set GID bit . . . : 0 Sticky bit . . . . : 1 ...` In the line for the sticky bit, `1` indicates that the sticky bit is on.
The z/OS UNIX shell	Issue `ls -l` Result: You will see a display similar to the following: `-rwxr--r-T 2 SUPERU SYS2 131072 Oct 25 10:19 daemon1` `T` indicates that the sticky bit for daemon1 is on.

Rules:

If the daemon module resides in the file system, the file containing the daemon module must have the program control extended attribute set.
If the program does have the extended attribute set, you still need to verify that the file system that it resides in is not mounted with the NOSETUID option. Do one of the following:
- Check the MOUNT statement in BPXPRMxx.
- Display the file system information by using the df command. The file system, the mount table, and ISHELL have attributes that enable you to see this setting:
```
Ignore SETUID  . . . . : 1
```
  If the "Ignore SETUID" value is set to 1, loading modules from this file system will mark your address space dirty. For more information about dirty address spaces, see Handling dirty address spaces.