PASSWD_OVERRIDE(5) Domain/OS BSD PASSWD_OVERRIDE(5)
NAME
/etc/rgy/passwdoverride
DESCRIPTION
The passwdoverride administrative file lets you override password,
GECOS, home directory, and shell entries from the registry database. The
passwdoverride file is stored on each host machine participating in the
Passwd Etc registry. Any changes you make to it are in effect for the
local machine only, and have no effect on the centralized registry.
You may find passwdoverride especially useful for excluding people from
using certain machines, establishing local root passwords, or tailoring
local user environments.
The override feature is enabled by policy information stored in the
registry database. Using the edrgy command, you can can control how
much, if any, customization will be allowed.
PASSWDOVERRIDE FILE FORMAT
The format of the passwdoverride entries is similar to entries in the
UNIX password file. The format is:
person.group.org:passwd:uid:grp_id:GECOS:home_dir:shell
The colons that separate fields are required. You must enter them, even
if you are leaving the field blank.
Key Fields
The person.group.org and uid fields are key fields. You must enter one
of them to identify the account for which you are making overrides. The
following rules apply to entering these fields:
⊕ If you enter person.group.org, uid is ignored.
⊕ If you want to use uid as the key, enter %.%.% for the person.group.org
subject identifier.
Field Descriptions
Each of the fields in the passwdoverride field is described below.
person.group.org Is the Passwd Etc subject identifier that identifies
accounts. The subject identifier is similar to a UNIX
login name, but can contain a group and organization
identifier. This field is a key field. You must
enter it (or the uid) to identify the account.
passwd Is the encrypted password. You can specify an
override in this field. If you do, the password you
enter here will be in effect for this local machine
only. For no override, leave the field empty.
uid Is the UNIX user ID. Like person.group.org, this
entry is a key. You must enter it (or a subject
identifier) to identify the account. Enter a uid
when you want to apply the overrides to all a user's
accounts and aliases (regardless of the group or
organization). uids are especially useful for
overrides to root (uid 0). If, for example, root has
an alias of wizard, an override keyed by subject
identifier applies only when root logs in as root,
not when root logs in as wizard. If the override is
keyed by uid, it applies when root logs in as root or
wizard or any other alias.
grp_id Is the account's group ID. This field cannot be
overridden and is ignored when the passwdoverride
file is processed. Normally you should leave this
field empty.
GECOS Is the account's GECOS field. You can specify an
override in this field. To keep it unchanged, leave
it empty.
home_dir Is the account's home directory. You can specify an
override in this field. To keep it unchanged, leave
it empty.
login_shell Is the account's login shell. You can specify an
override in this field. To keep it unchanged, leave
it empty.
USING WILD CARDS TO IDENTIFY ACCOUNTS
You can use wild cards (%) for any part of the subject identifier. For
example, the entry:
smith.%.%
says that overrides affect user smith regardless of the group and
organization that smith logs in with. In other words, the overrides
affect all accounts for user smith.
The entry:
smith.xproject.development
restricts the overrides to a specific account. If smith has other
accounts, for example, smith.newproject.development or
smith.xproject.marketing, these are not affected by the override.
The entry:
%.%.marketing
applies the overrides to all members of the organization marketing.
USING ABBREVIATIONS
If you do not completely specify the subject identifier, wild cards are
assumed. For example, assume you are using passwdoverride to change a
user's home directory on a machine. To do this, you'd enter:
smith:::::/node6/smith:
An entry of smith.%.% is assumed for the subject identifier.
OVERRIDE PRECEDENCE
When more than one override file entry applies to an acccount, the most
specific entry is selected. Persons (person.%.%) are the most specific,
followed by user ID numbers, group (%.group.%), and organization
(%.%.org).
For example, assume the override file contains entries with the following
key fields:
⊕ marlena.%.%
⊕ %.dds.%
If a person logs on with the subject identifier of marlena.dds.rd, the
override keyed by marlena.%.% will be in effect. In this case, person
(marlena) is more specific than group (dds). Now assume the override
file also contains the entry marlena.dds.%. The override keyed by
marlena.dds.% will be in effect because person and group are more
specific than person alone (marlena.%.%) and more specific than group
alone (%.dds.%).
EXAMPLES
1.To prevent users from the evil_users organization from logging in to a
node, the entry in the passwdoverride file would be:
%.%.evilusers:ANINVALIDSTRING:::::
Note that entries for members of the evil_users group will be present
in the /etc/passwd file.
2.To change the password on a specific machine for the entire marketing
organization, the entry would be:
%.%.marketing:newpassword:::::
3.To change the password, home directory, and initial shell for the
smith.xproject.development account, the entry would be:
smith.xproject.development:newpassword:::/secret/xproject:/bin/sh
NOTES
Users can update their entries in the override file for the local host
using chfn, chhd, chsh, or passwd. Refer to the passwd manual page for
details.
SEE ALSO
getpwent(3), login(1), crypt(3), passwd(1), group(5), finger(1), rgyd(8),
edrgy(8)