addxusers(ADM)

Syntax

Description

file should be in traditional passwd(F) format (as found on XENIX^® systems).

If no file is given, addxusers does not attempt to add any new users and only performs certain consistency checks on the existing user accounts.

addxusers reads from the standard input if file is specified as ``-''.

Login names must begin with a lowercase letter (this may be overridden using the -f option), must not already exist, must not contain a slash (/), and must not be longer than 8 characters.

Numeric user IDs must not be already assigned (this may be overridden using the -f option), and must be in the range 0 to 60000 (inclusive).

Numeric group IDs must be in the range 0 to 60000 (inclusive). Groups that are missing from the file /etc/group generate a warning; membership in groups associated with protected subsystems also generate warnings.

Encrypted passwords are preserved; users are able to use their old XENIX passwords to log onto the new system.

Any password aging information that is present is translated into the equivalent expiration parameters.

The comment field, initial working directory (home directory), and login shell are preserved. addxusers warns about missing or inaccessible directories and shells, and non-absolute pathnames. Users should not share home directories.

addxusers takes the following options:

-e

Applies the same checks to existing users as those for new users (except for membership in a protected subsystem group).

Normally, only minimal checks for corruption are carried out on the existing /etc/passwd file before the new users are added: checks are only performed for duplicated login names or numeric user IDs, and bad format. These are all fatal errors, and prevent any new users from being added.

-f

Forces addxusers to allow multiple accounts with the same UID, or accounts with names beginning with a digit or non-alphanumeric character. addxusers also displays a warning message.

-s

Checks the existing users for membership in a protected subsystem group. As with new user accounts, not all of the problems that may be discovered are fatal (many are only warnings).

Duplicate group names or numeric group IDs in the /etc/group file generate warnings. However, if a protected subsystem group is corrupted in this way, this is a fatal error (no users are added).

-t type

Sets the type of each created user; if omitted, each user is classified as an ``individual''. The legal type values are:

Number	Name in prpw	Name in authsh	Comment
0	root	superuser	All-powerful user (UID 0).
1	operator	operator	Various classifications of
2	sso	security officer	anonymous system
3	admin	administrator	admininstration accounts.
4	pseudo	pseudo-user	General-purpose anonymous user.
5	general	individual	An individual's personal account.
6	retired	retired	An account that is no longer used.

 Number   Name in prpw   Name in authsh     Comment
 0        root           superuser          All-powerful user (UID 0).
 1        operator       operator           Various classifications of
 2        sso            security officer   anonymous system
 3        admin          administrator      admininstration accounts.
 4        pseudo         pseudo-user        General-purpose anonymous user.
 5        general        individual         An individual's personal account.
 6        retired        retired            An account that is no longer used.

You can specify type as a number, a name from the Protected Password database prpw(F), or as the name reported by authsh(ADM).

-u

addxusers expects file to contain a list (one per line) of usernames to add to the Protected Password database. Each user must already have an entry in XENIX format in /etc/passwd; this is used to make an equivalent entry for the user in the Protected Password database. This allows the system administrator to add entries manually to the /etc/passwd file, then easily correct the protected password database to reflect these additions.

-v

Displays a ``being processed'' message (which includes the username) for each user addxusers attempts to add to the system.

Examples

1. Back up the home directories of the users on the XENIX system using cpio(C) or tar(C). (Do not back up these files using absolute pathnames. For example, if your accounts are in /usr, run your backup command from that directory, not from /.)

2. Make a copy of /etc/passwd and /etc/group from the XENIX system. (Do not back these files up with absolute pathnames either.)

3. After making certain you are in single user mode, extract the backup of the user's home directories on the new system. For example, if your user accounts reside in /usr, the files should be extracted in /usr on the new system. (Note that if you are using a mounted filesystem for your accounts, you must mount it before extracting your backups.)

4. Extract the copy of the passwd and group files in a temporary directory; for example, /tmp/passwd and /tmp/group. Be careful not to overwrite the /etc/passwd and /etc/group files on the new system.

5. Edit /tmp/passwd to remove ``system'' accounts (such as root and bin) and any accounts that already exist on the new system.

6. Separate the remaining accounts in /tmp/passwd (which are to be added to the new system) into different files by user type. For example, place all ``pseudo-users'' in a file called /tmp/pseudo and all ``individual'' users in /tmp/individual.

7. In your sorted /tmp account files, you should change login names, numeric user IDs, numeric group IDs, initial working directories, and shell programs as necessary to prevent conflicts with any accounts already on the new system. (If any numeric user or group IDs are changed, it may be desirable to chown(C) or chgrp(C) the appropriate home directories and their contents on the new system.)

8. Merge /tmp/group (the saved copy of the XENIX system's /etc/group) with the new system's /etc/group; see group(F). Again, make certain you are still in single-user mode; if /etc/group is modified while in multi-user mode, no-one will be allowed to login.

9. Run addxusers:
   
   addxusers -t pseudo-user /tmp/pseudo 2>&1 | tee -a /tmp/errors
   addxusers -t individual /tmp/individual 2>&1 | tee -a /tmp/errors
   .
   .
   .

   (If the /tcb/bin is not in the root PATH variable, you must specify the full pathname.) It is advisable to save the standard output and error output of addxusers (as shown above) for later analysis and correction.

The authorizations may need customization. Accounts that are neither individuals nor retired should be assigned ``account which may su''.

Limitations

Accounts without passwords and other liberties that XENIX allows are more restricted in UNIX System V. To continue to use such poor security practices requires customizing the system defaults or the insecure accounts.

Some standard accounts shipped with the system provoke warnings when the -e or -s options are specified.

Some vendors' systems support specifying a nice(S) value in the comment field, or doing a chroot(S) to the home directory (called a sublogin). Both constructions are understood by addxusers, and the nice value is supported, but sublogins are not in UNIX System V and cause a warning.

Authorization

See also

Standards conformance