addxusers(ADM) 19 June 1992 addxusers(ADM) Name addxusers - create new user accounts given a traditional password file Syntax /tcb/bin/addxusers [ -esuv ] [ -t type ] [ file ] Description addxusers reads the specified file, which should be in traditional passwd(FP) format (as found on XENIX systems), and creates the indicated accounts by making equivalent entries in the system's /etc/passwd file and Protected Password database. The auth subsystem and chown kernel authorizations are required to run addxusers. 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. A file of ``-'' means that the standard input should be read. Login names must begin with a lowercase letter, 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, and must be in the range 0 to 60000 (inclusive). Numeric group IDs must be in the range 0 to 60000 (inclusive). Groups which are missing from the file /etc/group generate a warning, as does membership in a group associated with a protected subsystem. Encrypted passwords are preserved; that is, users will be able to use their old XENIX passwords to log onto the new system. Any password-aging information which is present is translated into the equivalent expiration parameters. The comment field, initial working directory (home directory), and shell program are preserved. Missing or inaccessible directories and shells are warned about, as are non-absolute pathnames. Users should not share home directories. With the -u option, 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 /etc/passwd in XENIX format, which is used to make an equivalent entry for the user in the Protected Password data- base. This allows the system administrator to manually add entries to the /etc/passwd file, then easily correct the protected password database to reflect these additions. The -v option displays a ``being processed'' message (which includes the username) for each user addxusers attempts to add to the system. The -t option sets the type of each created user; if omitted, each user is classified as an ``individual'' person. The legal type values are: _________________________________________________________________________ Number Equivalent names Comments ______|__________|__________________|____________________________________ 0 | root | superuser | All-powerful user (numeric ID 0). 1 | operator | | Various classifications of 2 | sso | security officer | anonymous system administration 3 | admin | administrator | accounts. 4 | pseudo | pseudo-user | General-purpose anonymous user. 5 | general | individual | An individual's personal account. 6 | retired | | An account which is no longer used. 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.) The -e option causes the same checks which are applied to new users to be applied to the existing users (except for membership in a protected subsystem group). The -s option checks the existing users for membership of a protected subsystem group. As with new user accounts, not all of the problems which may be discovered are fatal (many are only warnings). Duplicated group names or numeric group IDs in the /etc/group file are warned about. However, if a protected subsystem group is corrupted in this way, this is a fatal error (no users are added). Example The following steps should be performed when migrating a community of users from a XENIX system: 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 path- names. 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 file- system for your accounts, you must mount it before extracting your backups.) 4. Extract the copy of the passwd and group files in a temporary direc- tory; 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 ``in- dividual'' 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. Finally, use the Accounts -> User -> Examine menu of sysadmsh(ADM) to customize the newly-created accounts as needed. The authorizations may need customization, and accounts which are neither individuals nor retired should have an ``account which may su'' assigned. See also authcap(F), chgrp(C), chown(C), cpio(C), group(F), passwd(FP), rmuser(ADM), su(C), sysadmsh(ADM), tar(C), tee(C), unretire(ADM) Notes When logging in, XENIX truncates passwords to eight (8) characters; SCO System V does not. Therefore, the user must not type more than eight characters when the password from the XENIX system is in effect. Passwordless accounts and other liberties XENIX allows are more re- stricted in SCO System V. To continue to use such poor security prac- tices requires customizing the system defaults or the unsecure accounts. Some standard accounts shipped with the system provoke warnings when the -e or -s options are specified. Some vendor's 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 SCO System V and cause a warning. Value added addxusers is an extension of AT&T System V provided by The Santa Cruz Operation, Inc.