Open System Services Porting Guide (G06.29+, H06.06+, J06.03+)
entries is denied. This behavior matches the behavior for G-series RVUs, H06.19 and
earlier H-series RVUs, and J06.08 and earlier J-series RVUs.
For information about the NFSPERMMAP attribute for OSS filesets, see the Open System
Services Management and Operations Guide.
For a detailed description of OSS ACLs, including examples, see the acl(5) reference page
either online or in the Miscellaneous Topics section of the Open System Services System Calls
Reference Manual.
On systems running J06.11 or later J-series RVUs or H06.22 or later H-series RVUS:
• Version 3 OSS filesets can be configured as restricted-access filesets. A fileset is a
restricted-access fileset if the RESTRICTEDACCESS attribute for that fileset has a value of
ENABLED or LOCAL. Restricted-access filesets deny the super ID (255,255 in the Guardian
environment, 65535 in the OSS environment) special access privileges. In restricted-access
filesets, the super ID is restricted by the same file permissions and owner privileges as any
other user ID: It has no special privileges unless the executable file started by the super ID has
the PRIVSETID file privilege. In this case, the process started by the super ID can switch to
another ID and then access files in restricted-access filesets as that ID.
• Files have an additional privilege attribute that specifies which special privileges, if any, a
file has when accessing files in a restricted-access fileset. For example, the executable files
for the Backup and Restore 2 software product can be given the PRIVSOARFOPEN file privilege
to allow the Backup and Restore 2 software product, when started by a locally-authenticated
member of the Safeguard SECURITY-OSS-ADMINISTRATOR (SOA) group, to back up and
restore files that are in a restricted-access fileset.
For more information about restricted-access filesets and file privileges, see the Open System
Services Management and Operations Guide. For more information about Safeguard security
groups, see the Safeguard Reference Manual.
Security Interoperability
There is some security interoperability between Guardian and OSS environments. All processes
have the same identity attributes, and an object-oriented control model is used. A process’s effective
user ID (EUID) and its process access ID (PAID) are kept synchronized by OSS functions and
Guardian procedure calls. Guardian disk file access control has been generalized to use a process’s
effective group ID (EGID) and group list. The execution of a PROGID program alters the child
program’s identity in the same manner as does the execution of a set-user-ID and set-group-ID
program.
UNIX programs ported to the OSS environment (without using the additional features provided by
Guardian process attributes or Guardian files) should see very little, if any, difference in behavior
when executed in the OSS environment. It is only when these programs access Guardian files or
processes or use Guardian features using Guardian procedure calls that a difference in behavior
is noticed. API interoperability aspects are discussed further in Chapter 5 (page 71). See also
“Using HP Extensions” (page 129).
OSS C Programming Considerations
The OSS C compilers for the TNS/R and TNS/E native environments support the ISO/ANSI C
standard, Common C, plus extensions specific to HP. The OSS C compiler for the G-series TNS
environment supports the ISO/ANSI C standard, plus extensions specific to HP. An OSS TNS C
compiler is not supported for TNS/E systems.
ISO/ANSI C adds a number of features and capabilities not present in Common C. Many of these
features are listed in “ISO/ANSI C Standard and the HP NonStop C Compiler” (page 26). Because
the definition of ISO/ANSI C is more precise than Common C, UNIX programs written in
ISO/ANSI C are more portable and easily maintained. This subsection deals with porting programs
written in Common C to the OSS environment. See Chapter 2 (page 31) for a discussion on the
differences between the C compilation tools in the native and G-series TNS environments.
OSS C Programming Considerations 115