NIST POSIX TEST SUITE, install and go

Posix Test Suite docker(110) downloads, tar, install
https://qiita.com/kaizen_nagoya/items/f1e24be04a2405ede00f

NIST POSIX TEST Suite on macOS
https://qiita.com/kaizen_nagoya/items/e24bd7a3710274372cc1


>5. Getting Started
5.1 User Accounts
This PCTS should be installed into a newly created test user account. The sole purpose of this account should be to run the PCTS test suite.
The user-ID and group-ID for the test user account should contain different values for user-ID and group-ID. The test directory where the PCTS is to be loaded must be set to the test user’s user-ID and group-ID.
The user account login name must agree with the config (§B) required parameter LOGNAME.
5.2 Environment
This PCTS requires that the tester execute with no restrictions on created files.
<1>
• Execute: umask 0
5.3 Reading the Distribution
The NIST-PCTS:151-2 is distributed in extended cpio data interchange format.
Login as the tester and transfer the PCTS to the implementation to be tested. Modification time of files on the NIST-PCTS:151-2 distribution must be preserved or failures will be reported during verification.
<2>
• Execute: cd tester_login_directory
cpio -icBdmu[v] < distribution_file
Note1: The actual command to read the NIST-PCTS:151-2 distribution may vary on your implementation.
Note2: We read the NIST-PCTS:151-2 distribution from a networked remote tape drive with the command:
rsh remote_host dd if=/dev/rmt0 ibs=5120 | cpio -icBdumv
Note3: The NIST-PCTS:151-2 distribution contains 7360 blocks.
5.4 Apply Applicable Patch
Apply the latest FIXES Patch and BETA Patch if applicable. These patches are distrbuted by e-mail to those who have purchased the NIST-PCTS:151-2 and have registered with NIST/CSL. To register with NIST/CSL send an e-mail message to 151-2@sst.ncsl.nist.gov. (See Appendix G for procedures for installing patches).
<3>
• Strip off e-mail header info from FIXES_PATCH_mm_dd_yy.
• Execute: sh FIXES_PATCH_mm_dd_yy 2>FP
Ensure no problems were encountered.
<Φ> This step installs the active BETA Patch. This step should only be performed for BETA testing.
• Execute: sh BETA_PATCH_mm_dd_yy 2>BP
Ensure no problems were encountered.
5.5 Owner and Group Adjustment
The files read must be provided with the proper user ID and group ID of the tester. The procedure for accomplishing this can vary among implementations.
<4>
• Ensure: ThePCTS files are owned by the tester and have the tester’s group ID.
Note: On our implementation we perform the following commands.
chown -R tester NIST-PCTS
chgrp -R tester NIST-PCTS
5.6 Tape Contents
The NIST-PCTS:151-2 distribution contains the following directory trees:
CERT_data - certification modules
DOCS - documents (written for troff and mm macros)
STD - POSIX.1 source test modules
STD/DEF - POSIX.1 Chapter 2 (Definitions & General Requirements)
STD/PP - POSIX.1 Chapter 3 (Process Primitives)
STD/PE - POSIX.1 Chapter 4 (Process Environment)
STD/FD - POSIX.1 Chapter 5 (Files & Directories)
STD/IO - POSIX.1 Chapter 6 (Input & Output)
STD/DC - POSIX.1 Chapter 7 (Device & Class-Specific Functions)
STD/LS - POSIX.1 Chapter 8 (C Programming Language)
STD/PW - POSIX.1 Chapter 9 (Passwords)
STD/DIF - POSIX.1 Chapter 10 (Data Interchange Format)
bin -executable file depository
data - used by utility verify
include - headers
lib -archive library files depository
src - commands, libraries, etc
src/Aids - configuration files to test IUT for specific operating system
src/tools - libraries
scripts - used by utility install
tmp - used by utility verify
5.7 NIST-PCTS:151-2 Modules
The NIST-PCTS:151-2 provides the following utilities:
• install
The install command builds the executable modules of the NIST-PCTS:151-2.
• verify
The verify command is the NIST-PCTS:151-2 driver. It can execute test components on an individual or on a SECTION-by-SECTION basis. The verify command has some options, when executed on a SECTION-by-SECTION basis only, which control the amount of data to be retained from running a test component. The -d option retains the temporary files. The -k option retains the Raw Journal Report files for each test component in the associated adm directory under the name
.component_test_name. The -K option retains the Raw Journal Report only if an error in testing was detected. The default is no options. On completion of each test component, verify will produce an output report.
When verify is executed on a component basis the Raw Journal Report is the only journal provided, and this is sent to the standard output device.
• setaccess
The setaccess module traverses the entire NIST-PCTS:151-2 directory tree and assigns the proper ownership and protection modes to selected component test modules, data files and directories. Module setaccess touches each data file and will report all missing data files.
• clraccess
The clraccess module traverses the entire NIST-PCTS:151-2 directory tree and resets the ownership and protection modes set by setaccess to their original modes.
• validate
The validate module compares the tests result codes from the output journals with the expected test result codes and reports all discrepancies to stdout.

> 6. NIST-PCTS:151-2 Configuration Procedures
When the NIST-PCTS:151-2 is to be rerun for an IUT, then skip to §6.4 to reinstall the configuration files.
6.1 install
The install utility builds the executable modules of the NIST-PCTS:151-2.
The NIST-PCTS:151-2 support utilities are Strictly Conforming Applications. These utilities will compile and execute on all POSIX.1 Conforming Implementations. To allow an implementation’s utilities to interface with the NIST-PCTS:151-2 support utilities, this PCTS allows the tester to define the command syntax for the implementations utilities. The <install.h> header file specifies the syntax for the
implementation utilities.
The symbol PATH_CMD will be prefixed to commands which do not begin with a ‘‘/’’. This allows commands to be specified without a common absolute pathname. Commands must be regular, executable
files, not shell scripts.
<5>
• Edit <install.h> to define PATH_CMD and
the command syntax for all the commands specified in struct cmd_imp.
NOTE: Some of the assertion tests rely on the ’C’ compiler to provide the required testing. The APTL must exert proper judgement to ensure that if compilation flags are used for compilation commands they do not suppress
warnings that are actually FIPS 151-2 errors.
• If your implementation supports the System V ar/ld combination, then the ranlib command is not required.
The module ./src/install/s_install is a script file that contains the commands for compiling and loading the install program.
<6>
• Modify s_install as needed by the IUT to compile and install
the install program..
6.2 Target System Support Library
The NIST-PCTS:151-2 uses a library to interface required target system support facilities. File tssf.c in directory ./src/tools/tssf is provided as an example. The target system support routine will be archived in library ./lib/tssf.a.
6.2.1 Terminal Device Configuration
Many tests in this PCTS require two interconnected terminal device files. This section specifies the configuration and what is required from the installed configuration.
Two interconnected terminal device ports on the same machine, with each port simulating the presence of a terminal provides for error-free and repeatable testing. Currently, only those implementations which have a hardware configuration with at least two asynchronous communications ports available for use by this PCTS will be able to show compliance with those assertions that require this configuration.
The terminal special files corresponding to PORT_TTY and PORT_LOOP in ‘‘./include/config’’ should
be configured on the system with modem control enabled. The special files’ modes should be set to give
read and write permission to the test user account.
Terminal devices are required to test those assertion numbers listed in the tables of Section 12 of this document,
under the column marked GTI_dev.
When enabling asynchronous ports with a RS232 loop-back cable connection, GTI_dev marked assertion
tests expect to open each side on the loop-back connector without blocking, such that a blocking open()
would succeed. Data read/written on one port can be written/read on the other port respectively. Also a
last close() on one side (with HUPCL set) would de-assert the line such that the other side detects it. This
implies that the system asserts a RS232 line with RTS/CTS or DTR/DSR on open(), but also that any
form of hardware handshaking will not de-assert the opened line.
<7>
• Connect two terminal device ports back-to-back (closed-loop).
6.2.2 Mounting and Unmounting File Systems
Ability to mount and unmount file systems is an implementation feature not provided by POSIX.1.
POSIX.1 does require a conforming implementation to support read-only file systems and read-write file
systems.
To test these file systems the NIST-PCTS:151-2 requires the tester to provide the interface routines
mtrwfs(), mtrofs(), and unmtfs( ). This interface must successfully perform the functionality as described
below. The functionality can be performed programmatically or semi-manually.
Modules that use these interfaces are provided appropriate privileges.
6.2.2.1 Mount with Read/Write Capabilities
6.2.2.1.1 Synopsis
int mtrwfs(dirname, fsname)
char *dirname;
char *fsname;
6.2.2.1.2 Description
The mtrwfs( ) function will mount the file system specified by fsname on the mount point specified by
dirname. The file system mounted should be of size 10 kilobytes or larger. A mountable filesystem
much larger than 10 kilobytes will only result in a larger setup time when preparing to test assertions
which depend on a full file system. The mount point dirname will be specified by NIST-PCTS:151-2.
The file system must be mounted in a manner that allows both read and write access to the file system.
6.2.2.1.3 Returns
Upon successful completion, mtrwfs( ) shall return a value of zero. Otherwise, a value of -1 is returned.
6.2.2.2 Mount with Read Capabilities
6.2.2.2.1 Synopsis
int mtrofs(dirname, fsname)
char *dirname;
char *fsname;
6.2.2.2.2 Description
The mtrofs( ) function will mount the file system specified by fsname on the mount point specified by
dirname. The mount point dirname will be specified by NIST-PCTS:151-2. The file system must be
mounted in a manner that allows only read access to the file system.
6.2.2.2.3 Returns
Upon successful completion, mtrofs( ) shall return a value of zero. Otherwise, a value of -1 is returned.
6.2.2.3 Unmount a File System
6.2.2.3.1 Synopsis
int unmtfs(dirname, fsname)
char *dirname;
char *fsname;
6.2.2.3.2 Description
The unmtfs() function will unmount the file system specified by fsname which is currently mounted on
the mount point specified by dirname. On completion the specified directory dirname may be used as
the mount point for another file system.
Both the directory name and the file system are passed to this function as it is unknown which of these
will be used to effect the unmount.
6.2.2.3.3 Returns
Upon successful completion, unmtfs() shall return a value of zero. Otherwise, a value of -1 is returned.
6.2.3 Establish a Controlling Terminal
Ability to establish a controlling terminal is an implementation feature not provided by POSIX.1.
POSIX.1 does allow a conforming implementation to support a general terminal interface for controlling
asynchronous communications ports.
A conforming implementation that supports asynchronous communications ports must interface to the
routine open_ctty( ). This interface must successfully perform the functionality as described below.
6.2.3.1 Establish a Controlling Terminal
6.2.3.1.1 Synopsis
int open_ctty(path, flags, mode)
char *path;
int flags;
mode_t mode;
6.2.3.1.2 Description
The open_ctty( ) function will establish the terminal device specified by path as the controlling terminal
with permissions of mode.
6.2.3.1.3 Returns
Upon successful completion, open_ctty( ) shall open the controlling terminal device and shall return a
non-negative integer representing the file descriptor for the controlling terminal device. Otherwise, a
value of -1 is returned.
6.2.4 Configuring Target System Support Facilities
<8>
• Edit file tssf.c in ./src/tools/tssf as required for your implementation.
6.3 config
The NIST-PCTS:151-2 uses the file <config> to specify all the installation parameters required for testing
POSIX.1 conformance. Appendix B provides the explanation of the symbols used in <config> and
the details on the specifications of what is required of the tester to define the IUT.
NOTE: APTL’s should complete the template in Appendix A of NIST POSIX Testing Policy— Certificate of Validation Requirements
for FIPS 151-2 before tackling the configuration of <config>. By following this systematic approach, much of the input
required by <config> will have been derived from the PCD and the data reported by the APTL, for this template, will agree
with that used by <config>.
<9>
• Edit <config> to define all required parameters.
The ./scripts directory contains script files which are used by install to compile and install the
NIST-PCTS:151-2 modules. Scripts exist for compiling and installing this PCTS.
6.4 Reinstall of Configuration Files
Once the IUT has been configured, steps <5> thru <9> completed, all the configuration files required for
the IUT should be placed into a non-hierarchial test directory.
When the configuration files to be modified for the IUT are available in a single directory, the script file,
./bin/config_iut, is available for the tester to use. When this script is executed the NISTPCTS:
151-2 configuration files present in the directory specified will be installed. The NIST-PCTS:151-2
distribution configuration files will be retained with a trailor label name of ‘‘_DISTR’’.
<5-9>
• Example: ./bin/config_iut ./src/Aids/oper_system
This script file may be executed repeatedly during configuration procedures.
A tester’s procedure should be to copy the changed configuration files to a test directory once the configuration
files are initially established. If configuration are to be modified, then only perform the changes in
the test directory and execute ./bin/config_iut to reinstall all configuration files needed. This procedure
simplifies the task of updating and maintenance of configuration files for an IUT.
The directory ./src/Aids contains anonymous contributions of configuration files that have been used
on specific implementations. No guarantees or claims are associated with these files that when used on
the hardware and operating system stated that the IUT will sucessfully run the NIST-PCTS:151-2. Further
more, no guarantees or claims are associated with these files that they were configured properly for
the NIST-PCTS:151-2 nor the IUT tested. These configuration files are provided as examples of what a
tester did use to run a version of the NIST-PCTS:151-2 during its development. A tester may be able to
use one of the sets of configuration files provided to test an IUT.
7. Installing NIST-PCTS:151-2
7.1 Install Modules
Install the install program.
<10>
• Execute: cd ./src/install
• Execute: ./s_install
• Execute: cd ../..
The NIST-PCTS:151-2 libraries, verify, setaccess and clraccess modules can now be installed.
The time required on a 20 SPECmark system was approximately 20 minutes (120 SPECmark system, 8
minutes).
The output from install, Installation Report, is generated as the filename journal. To ensure a prior
Installation Report is retained, rename the output filename. If a Certificate of Validation is to be obtained,
the Installation Report obtained from the execution of ./scripts/utilities must be renamed to
util_inst_rep.
<11>
• Execute: ./bin/install ./scripts/utilities
• Correct any Installation Report errors and warnings that violate
FIPS 151-2 conformance requirements before continuing.
• Execute: mv journal util_inst_rep
7.2 Install Test Components
The test components can now be installed. The time required on a 20 SPECmark system was approximately
2.25 hours (120 SPECmark system, 35 minutes).
<12>
• Execute: ./bin/install ./scripts/NIST-PCTS
• Correct any Installation Report errors and warnings that violate
FIPS 151-2 conformance requirements before continuing.
NOTE: Test load module names have a length less than {POSIX_NAME_MAX}. Each test module’s name is derived from the
POSIX.1 subclause designation and the corresponding POSIX.3.1 starting assertion number being tested. (Ex. The name for the
module that tests assertion #4 of fork( ) would be 3.1.1_04.) When multiple functions have the same POSIX.1 subclause designation,
then an additional alphabetic letter follows the POSIX.1 subclause designation. (Ex. The name for the module that starts
with code to test assertion #4 of wait() and waitpid( ) would be 3.2.1a_04 and 3.2.1b_04 respectively.) When a test requires multiple
load modules then succeeding modules are designated with a trailing alphabetic letter starting with ‘‘x’’.
NOTE: When multiple POSIX.1 functions have similar requirements for testing. Instead of the assertion number, a name designation
is provided. The complete set of tests that have this designation are:
syn synopsis section testing
pth pathname testing
acc access testing
7.3 Special Files
<13>
• If IUT supports character special devices, then create a character
special file with pathname of
./STD/DIF/data/dif.d/type.d/mode_cks.d/S_ISCHR
with the user ID and group ID of the tester.
Example:
mknod ./STD/DIF/data/dif.d/type.d/mode_cks.d/S_ISCHR c 77 77
chown tester ./STD/DIF/data/dif.d/type.d/mode_cks.d/S_ISCHR
chgrp tester ./STD/DIF/data/dif.d/type.d/mode_cks.d/S_ISCHR
• If IUT supports block special devices, then create a block
special file with pathname of
./STD/DIF/data/dif.d/type.d/mode_cks.d/S_ISBLK
with the user ID and group ID of the tester.
Example:
mknod ./STD/DIF/data/dif.d/type.d/mode_cks.d/S_ISBLK b 77 77
chown tester ./STD/DIF/data/dif.d/type.d/mode_cks.d/S_ISBLK
chgrp tester ./STD/DIF/data/dif.d/type.d/mode_cks.d/S_ISBLK
7.4 Special Permissions
The NIST-PCTS:151-2 requires many of the modules in the test suite to execute as a specific user and
many of the data files and directories to possess special ownership and/or permissions. The setaccess
module provides these attributes. This module must be setup to execute as the super-user.
<14>
• As the super-user, set the owner of ./bin/setaccess to be super-user
and set the mode bits S_ISUID, S_IXUSR and S_IXGRP.
<15>
• Execute: ./bin/setaccess
7.5 Data Interchange Format
A conforming implementation must be able to read and write both cpio and extended tar data interchange
formats. The NIST-PCTS:151-2 uses a set of data files to create cpio and extended tar
archives. A Bourne shell script is used to establish test files. This script creates the cpio and extended
tar archives with its header and source data using characters as represented in ISO/IEC 646 IRV, and
extracts data files from the PCTS distributed cpio and extended tar archives.
<16>
• Header file <iso646_natv.h> specifies a mapping between ISO/IEC 646 IRV and the
IUT’s local codeset.
Edit <iso646_natv.h> if needed.
<17>
• Edit the script ./bin/dif_script for proper functioning on the
implementation to be tested.
• Execute script file: ./bin/dif_script


8. Testing NIST-PCTS:151-2
8.1 Functional Interfaces
The NIST-PCTS:151-2 provides for the tester to sequentially run all the test components by executing a
single command (verify). The Raw Journal Report for each component tested is placed in the file
./STD/POSIX_CHAPTER/adm/.test_component and the Output Report is placed in the file
./STD/POSIX_CHAPTER/adm/journal. The POSIX_CHAPTER designation is the appropriate
directory DEF, PP, PE, FD, IO, DC, LS, PW, DIF corresponding to the POSIX chapter where the test
component is specified. The time required to execute Step <18> on a 20 SPECmark system was approximately
90 minutes.
<18>
• Execute: ./bin/setaccess (Additional insurance)
• Execute: ./bin/verify IUT
NOTE: A report submitted to NIST/CSL for FIPS 151-2 Validation, when adequate storage exists, must have been generated by
the preceding command. When the implementation has limited storage and can only compile and execute the PCTS in sections,
then the sections of the report must be installed and verified in the following order: STD/DEF, STD/PP, STD/PE, STD/FD,
STD/IO, STD/DC, STD/LS, STD/PW, STD/DIF (See NIST POSIX Testing Policy— Certificate of Validation Requirements for
FIPS 151-2).
Test components may be run a setion or multiple section at a time by specifying the appropriate test directory
to verify.
<Ex.>
• Execute section ‘‘Files and Directories’’ tests:
./bin/verify -k STD/FD
• Execute multiple section tests:
./bin/verify -k STD/DEF STD/PP STD/PE STD/FD
Test components may be run a component at a time by specifying the test component to verify. When
verify is executed by test component the Raw Journal Report is only outputted to the standard output
device.
<Ex.>
• Execute component: ./bin/verify STD/FD/link

9. Reports
The NIST-PCTS:151-2 produces three reports.
9.1 Installation Report
The Installation Report captures all the commands that are used to generate the NIST-PCTS:151-2 utilities
and test modules and all output results reported by the implementations utilites used. Installation
reports are placed in the file journal. Move any journals you want to save to another file before running
the install command again.
An example of the Installation Report is provided in Appendix C.
9.2 Raw Journal Report
The Raw Journal Report provides a step-by-step log of what the NIST-PCTS:151-2 requires for each test,
the preparations taken for each test, and the results of each test. This log is in sufficient detail such that
any failure can be quickly pointed to a specific line of the actual source code where the test failed.
Raw journal reports, if the -k or -K option (See §5.7, verify) is used, are placed in the
./STD/Section/adm directories. Where Section is the name of a particular section, e.g., FD. A
separate Raw Journal Report is generated for each component tested. The name of each Raw Journal
Report is the name of the component preceded by a ‘.’. (e.g., The Raw Journal Report for link() is .link.
A Raw Journal Report for cfgetispeed( ) is provided in Appendix E.
9.3 Output Report
The NIST-PCTS:151-2 output report is based on the IEEE Std 1003.3-1991. The report consists of a test
result code for every assertion of each element. The test result code is one of the following:
• PASS - successful test of a base assertion.
• FAIL - unsuccessful test of a base assertion.
• PASS_EXTENDED - successful test of an extended assertion.
• FAIL_EXTENDED - unsuccessful test of an extended assertion.
• UNTESTED - the test for this extended assertion does not exist for the target system.
• UNSUPPORTED - the conditional feature was not tested because it was not implemented.
• NOT_APPLICABLE - The assertion is not applicable to the profile as required by FIPS
151-2.
• NOT_TESTABLE - The implementation lacks a PCTS required testing constraint (GTI
devices are not provided) or a PCTS testing parameter’s value ({PCTS_NAME_MAX}) is
not applicable to the value required by the assertion’s testing constraint.
NOTE: When the PCTS determines that the testing constraint has not been satisfied, the PCTS uses
NOT_TESTABLE instead of the POSIX.3.1 specified test result code of UNTESTED. When a POSIX.3.1 testing
constraint assertion is extended and the code to test the assertion is provided, the test result code is UNTESTED.
• UNRESOLVED - the test for the assertion could not be completed. Tw o examples are: 1) a
directory was required before the assertion could be tested, and mkdir() failed; 2)An unexpected
signal was sent to the test driver, causing the test to abort. An UNRESOLVED test
result code is an intermediate result that is required to be resolved to one of the other test
result codes.
• NOT_INITIATED - No test was run for this assertion number. This test result code is normally
the result of an earlier failure in a test module. See the Raw Journal Report to determine
the reason for failure.
The NIST-PCTS:151-2 shall output UNUSED instead of a test result code for assertion numbers in the
UNUSED list of each element. UNUSED means there is no assertion associated with the number.
Output reports are placed in the ./STD/Section/adm directories. Where Section is the name of a
particular section, e.g., FD. The name of the output reports are journal.
An example of the Output Report is provided in Appendix F.
A list of potential problems and possible solutions is provided in Appendix H.
10. FIPS 151-2 PCTS Conformance Testing
10.1 Type Checking
The detection of type checking non-conformity relies upon the ANSI C compiler to generate an error or a
warning message.
<1>
• Ensure no errors or warnings , which imply errors, are reported in the
compilation phase of the PCTS.
When such warning or errors occur, the corresponding final test result codes
are FAIL even if the NIST-PCTS:151-2 reports them as PASS.
10.2 Required Test Result Codes
The following tables provide the acceptable test result codes other than PASS for each assertion in IEEE
Std 2003.1-1992.
Terminology and General Requirements
Test Code UNSUPPORTED UNTESTED
Class Conditional Extended
Element # other
gen_terms 7 1-2,4-7
gen_concept 1 1
err_numbs 3 3
psd_types 5
env_descr 2
c_lang 5 5
num_lmts 17 4-15 16
sym_const 8 6-8
Additional test result codes:
PASS_EXTENDED — psd_types[5 ]


Process Primitives
Test Code UNSUPPORTED NOT_TESTABLE UNTESTED
Class Conditional Testing Constraint Extended
Element # macro other GTI_dev other
fork 28 2-3 20 5-6,26,28
execl 60 2-3 38 38,44-46,49,54-55 22-23,26-27,52,60
execv 60 2-3 38 38,44-46,49,54-55 22-23,26-27,52,60
execle 60 2-3 38 38,44-46,49,54-55 22-23,26-27,52,60
execve 60 2-3 38 38,44-46,49,54-55 22-23,26-27,52,60
execlp 60 2-3 38 38,44-46,49,54-55 22-23,26-27,52,60
execvp 60 2-3 38 38,44-46,49,54-55 22-23,26-27,52,60
wait 15 2-3
waitpid 27 2-3
_exit 13 2-3 11-12 6
signal_con 61 14-15,46 46,53,56 3,9,39,47-48,54,57
53,56,59,61
kill 20 2-3 16
sigemptyset 4 2-3
sigfillset 4 2-3
sigaddset 6 2-3 5 6
sigdelset 6 2-3 5 6
sigismember 6 2-3 5 6
sigaction 21 2-3
sigprocmask 14 2-3
sigpending 5 2-3 5
sigsuspend 9 2-3
alarm 9 2-3
pause 7 2-3
sleep 6 2-3
Additional test result codes:
NOT_APPLICABLE — execl[32 ], execv[32 ], exele[32 ], execve[32 ], execlp[32 ], execvp[32 ],
kill[19 ]
UNUSED — execl[9-15 ], execv[9-15 ], exele[9-15 ], execve[9-15 ], execlp[59 ], execvp[59 ]
Process Environments
Test Code UNSUPPORTED NOT_TESTABLE UNTESTED
Class Conditional Constraint Extended
Element # macro other GTI_dev other
getpid 4 2-3
getppid 4 2-3
getuid 4 2-3
geteuid 4 2-3
getgid 4 2-3
getegid 4 2-3
setuid 9 2-3 6-7 8
setgid 9 2-3 6-7 8
getgroups 7 2-3
getlogin 5 2-3 5
getpgrp 4 2-3
setsid 9 2-3 6,8-9 9
setpgid 16 2-3 11
uname 7 2-3 7
time 6 2-3 6
times 11 2-3 11
getenv 8 2-3 8
ctermid 8 2-3 4-5,7 8
ttyname 6 2-3 4 6
isatty 5 2-3 4
sysconf 19 2-3 15-16 17
Additional test result codes:
NOT_APPLICABLE — setuid[6-7 ], setgid[6-7 ], setpgid[12 ], sysconf[15-16 ]