However, instead of changing the UID and user profile for each user on each
system, administrators can use the QSYCHGID API (application programming
interface). This new API can be called fromAS/400 command lines, C programs,
COBOL programs, and through other interfaces as well. This function can change
the UIDs and GIDs of both system-provided profiles and regular user profiles. To
use this command, an administrator must include the following entries:
1. A ten-character profile name. This is the name of the user or system profile that
is to be changed. An example of such a profile name would be BILLor QUSER.
2. A UID value. This is the new value for the UID of the user or system profile that
you specified. Avalue of ’-1’ indicates that the UID will not change.
3. A GID value. This is the new value for the GID of the user or system profile that
you specified. Avalue of ’-1’ indicates that the GID will not change. A value of
’0’ indicates that the GID will be removed from the user or system profile.
4. A pointer to an error code structure. This pointer cannot be provided from a
command line, although it works through a programming interface. If a value of
’0’ is specified for this parameter, the user will be sent exceptions if the
command fails to function.
Tooperate QSYCHGID, an administrator must first end all jobs that are currently
running under the system or user profile name. If this is a system-provided profile,
AS/400 may require an entrance into “restricted state,” meaning that all interactive,
batch, daemon, and request jobs are ended. Youcan establish a “restricted state”
with the ENDSBS command. All that should be left operating is the system console,
the console that is directly attached to AS/400.
QSYCHGID will update a user or system profile with the appropriate UID value, as
well as all objects that a user or system owns. If the objects that are owned by a
user or system fail to be updated, then you should use the Reclaim Storage
(RCLSTG) command to reclaim any possible lost objects.
Note: QSYCHGID will always fail if a UID number is chosen that is already
allocated to an existing user or system profile. No UID value can belong to
more than a single profile.
Note: UIDs and GIDs are not mutually exclusive. That is, a UID value of 500 and a
GID value of 500 do not signify the same profile.
Securely Exporting File Systems
When namespace administrators export file systems, these are the rules they
should consider:
1. Use an exact list of clients who have access to mount and otherwise work with
the file systems that are exported. This will keep sensitive information out of the
reach of clients that are not listed with the ACCESS option of the OPTIONS
parameter of the CHGNFSEXP command.
2. Use QNFSANON extremely carefully when allowing anonymous UIDs access to
exported file systems. When coupled with the ROOT parameter, it can give
unknown (anonymous) users access to your namespace.
3. Always exclude access to the /etc/exports file. Do not export this file. A user
may find a way to access this file and make data available to other users that
would otherwise be safely guarded.
When administrators export file systems, they should never do the following:
Chapter9. Network File System Security Considerations 87