1
0
mirror of https://git.FreeBSD.org/src.git synced 2024-12-19 10:53:58 +00:00
freebsd/usr.bin/passwd/passwd.1

234 lines
7.4 KiB
Groff
Raw Normal View History

1994-05-27 12:33:43 +00:00
.\" Copyright (c) 1990, 1993
.\" The Regents of the University of California. All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" @(#)passwd.1 8.1 (Berkeley) 6/6/93
1999-08-28 01:08:13 +00:00
.\" $FreeBSD$
1994-05-27 12:33:43 +00:00
.\"
.Dd June 6, 1993
.Dt PASSWD 1
.Os BSD 4
.Sh NAME
.Nm passwd, yppasswd
1994-05-27 12:33:43 +00:00
.Nd modify a user's password
.Sh SYNOPSIS
.Nm passwd
.Op Fl l
.Op Ar user
1996-08-24 23:27:04 +00:00
.Nm yppasswd
.Op Fl l
.Op Fl y
.Op Fl d Ar domain
.Op Fl h Ar host
1996-08-24 23:27:04 +00:00
.Op Fl o
1994-05-27 12:33:43 +00:00
.Sh DESCRIPTION
.Nm Passwd
changes the user's local, Kerberos, or NIS password.
If the user is not the super-user,
.Nm passwd
first prompts for the current password and will not continue unless the correct
password is entered.
.Pp
When entering the new password, the characters entered do not echo, in order to
avoid the password being seen by a passer-by.
.Nm passwd
prompts for the new password twice in order to detect typing errors.
1994-05-27 12:33:43 +00:00
.Pp
The new password should be at least six characters long (which
may be overridden using the
.Xr login.conf 5
.if t ``minpasswordlen''
.if n "minpasswordlen"
setting for a user's login class) and not purely alphabetic.
1994-05-27 12:33:43 +00:00
Its total length must be less than
.Dv _PASSWORD_LEN
(currently 128 characters).
Numbers, upper case letters and meta characters
are encouraged.
.Pp
Once the password has been verified,
.Nm passwd
communicates the new password information to
the Kerberos authenticating host.
.Bl -tag -width flag
.It Fl l
This option causes the password to be updated only in the local
password file, and not with the Kerberos database.
When changing only the local password,
.Xr pwd_mkdb 8
is used to update the password databases.
.Pp
1994-05-27 12:33:43 +00:00
.El
When changing local or NIS password, the next password change date
is set according to
.if t ``passwordtime''
.if n "passwordtime"
capability in the user's login class.
1994-05-27 12:33:43 +00:00
.Pp
To change another user's Kerberos password, one must first
run
.Xr kinit 1
followed by
.Xr passwd 1 .
The super-user is not required to provide a user's current password
if only the local password is modified.
.Sh NIS INTERACTION
.Nm Passwd
has built-in support for NIS. If a user exists in the NIS password
database but does not exist locally,
.Nm passwd
automatically switches into
.if t ``yppasswd''
.if n "yppasswd"
mode. If the specified
user does not exist in either the local password database of the
NIS password maps,
.Nm passwd
returns an error.
Merge in changes to support the new rpc.yppasswdd(8) and fix a few bugs. In passwd(1): - Gut most of yp_passwd.c and leave only a few things that aren't common to pw_yp.c. - Add support for -d and -h flags to select domains and NIS server hosts to use when updating NIS passwords. This allows passwd(1) to be used for changing NIS passwords from machines that aren't configured as NIS clients. (This is mostly to allow passwd(1) to work on NIS master servers that aren't configured as clients -- an NIS server need not necessarily be configured as a client itself.) NOTE: Realize that having the ability to specify a domain and hostname lets you use passwd(1) (and chpass(1) too) to submit update requests to yppasswd daemons running on remote servers in remote domains which you may not even be bound to. For example, my machine at home is not an NIS client of the servers on the network that I manage, yet I can easily change my password at work using my FreeBSD box at home by doing: 'passwd -d work.net.domain -h any.nis.server.on.my.net wpaul'. (Yes, I do use securenets at work; temporarily modified my securenets file to give my home system access.) Some people may not be too thrilled with this idea. Those who don't like this feature can recompile passwd(1) and chpass(1) with -DPARANOID to restrict the use of these flags to the superuser. (Oh, I should be adding proper securenets support to ypserv(8) and rpc.yppasswdd(8) over the weekend.) - Merge in changes to allow root on the NIS master server to bypass authentication and change any user's NIS password. (The super-user on the NIS master already has privileges to do this, but doing it through passwd(1) is much easier than updating the maps by hand.) Note that passwd(1) communicates with rpc.yppasswdd(8) via a UNIX domain socket instead of via standard RPC/IP in this case. - Update man page. In chpass(1): - Fix pw_yp.c to work properly in environments where NIS client services aren't available. - Use realloc() instead of malloc() in copy_yp_pass() and copy_local_pass(). - Fix silly bug in copy_yp_pass(); some of the members of the passwd structure weren't being filled in correctly. (This went unnoticed for a while since the old yppasswdd didn't allow changes to the fields that were being botched.) - chpass(1) now also allows the superuser on the NIS master server to make unrestricted changes to any user's NIS password information. - Use UNIX domain comm channel to rpc.yppasswdd(8) when run by the superuser on the NIS master. This allows several new things: o superuser can update an entire master.passwd.{byname,byuid} entry o superuser can update records in arbitrary domains using -d flag to select a domain (before you could only change the default domain) o superuser can _add_ records to the NIS master.passwd maps, provided rpc.yppasswdd(8) has been started with the -a flag (to do this, the superuser must force NIS operation by specifying the -y flag to chpass(1) along with -a, i.e. 'chpass -y -a 'foo:::::::::') - Back out the 'chpass -a <new password entry> breaks with NIS' fix from the last revision and fix it properly this time. The previous revision fixed the immediate problem but broke NIS operation in some cases. - In edit.c, be a little more reasonable about deciding when to prevent the shell field from being changed. Submitted by Charles Owens <owensc@enc.edu>, who said: "I made a minor (one-line) modification to chpass, with regards to whether or not it allows the changing of shells. In the 2.0.5 code, field changing follows the settings specified in the "list" structure defined in table.c . For the shell, though, this is ignored. A quick look in edit.c showed me why, but I don't understand why it was written as such. The logic was if shell is standard shell, allow changing I changed it to if shell changing is allowed (per table.c) and it is a standard shell OR if uid=0, then allow changing." Makes sense to me. - Update man page.
1996-02-23 16:08:59 +00:00
.Pp
When changing an NIS password, unprivileged users are required to provide
their old password for authentication (the
.Xr rpc.yppasswdd 8
daemon requires the original password before
it will allow any changes to the NIS password maps).
This restriction applies even to the
super-user, with one important exception: the password authentication is
bypassed for the super-user on the NIS master server. This means that
the super-user on the NIS master server can make unrestricted changes to
anyone's NIS password. The super-user on NIS client systems and NIS slave
servers still needs to provide a password before the update will be processed.
.Pp
The following additional options are supported for use with NIS:
.Bl -tag -width flag
.It Fl y
The
.Fl y
flag overrides
.Nm passwd 's
checking heuristics and forces
it into NIS mode.
.It Fl l
When NIS is enabled, the
.Fl l
flag can be used to force
.Nm passwd
into
.if t ``local only''
.if n "local only"
mode. This flag can be used to change the entry
for a local user when an NIS user exists with the same login name.
For example, you will sometimes find entries for system
.if t ``placeholder''
.if n "placeholder"
users such as
.Pa bin
or
.Pa daemon
in both the NIS password maps and the local user database. By
default,
.Nm passwd
will try to change the NIS password. The
.Fl l
flag can be used to change the local password instead.
Merge in changes to support the new rpc.yppasswdd(8) and fix a few bugs. In passwd(1): - Gut most of yp_passwd.c and leave only a few things that aren't common to pw_yp.c. - Add support for -d and -h flags to select domains and NIS server hosts to use when updating NIS passwords. This allows passwd(1) to be used for changing NIS passwords from machines that aren't configured as NIS clients. (This is mostly to allow passwd(1) to work on NIS master servers that aren't configured as clients -- an NIS server need not necessarily be configured as a client itself.) NOTE: Realize that having the ability to specify a domain and hostname lets you use passwd(1) (and chpass(1) too) to submit update requests to yppasswd daemons running on remote servers in remote domains which you may not even be bound to. For example, my machine at home is not an NIS client of the servers on the network that I manage, yet I can easily change my password at work using my FreeBSD box at home by doing: 'passwd -d work.net.domain -h any.nis.server.on.my.net wpaul'. (Yes, I do use securenets at work; temporarily modified my securenets file to give my home system access.) Some people may not be too thrilled with this idea. Those who don't like this feature can recompile passwd(1) and chpass(1) with -DPARANOID to restrict the use of these flags to the superuser. (Oh, I should be adding proper securenets support to ypserv(8) and rpc.yppasswdd(8) over the weekend.) - Merge in changes to allow root on the NIS master server to bypass authentication and change any user's NIS password. (The super-user on the NIS master already has privileges to do this, but doing it through passwd(1) is much easier than updating the maps by hand.) Note that passwd(1) communicates with rpc.yppasswdd(8) via a UNIX domain socket instead of via standard RPC/IP in this case. - Update man page. In chpass(1): - Fix pw_yp.c to work properly in environments where NIS client services aren't available. - Use realloc() instead of malloc() in copy_yp_pass() and copy_local_pass(). - Fix silly bug in copy_yp_pass(); some of the members of the passwd structure weren't being filled in correctly. (This went unnoticed for a while since the old yppasswdd didn't allow changes to the fields that were being botched.) - chpass(1) now also allows the superuser on the NIS master server to make unrestricted changes to any user's NIS password information. - Use UNIX domain comm channel to rpc.yppasswdd(8) when run by the superuser on the NIS master. This allows several new things: o superuser can update an entire master.passwd.{byname,byuid} entry o superuser can update records in arbitrary domains using -d flag to select a domain (before you could only change the default domain) o superuser can _add_ records to the NIS master.passwd maps, provided rpc.yppasswdd(8) has been started with the -a flag (to do this, the superuser must force NIS operation by specifying the -y flag to chpass(1) along with -a, i.e. 'chpass -y -a 'foo:::::::::') - Back out the 'chpass -a <new password entry> breaks with NIS' fix from the last revision and fix it properly this time. The previous revision fixed the immediate problem but broke NIS operation in some cases. - In edit.c, be a little more reasonable about deciding when to prevent the shell field from being changed. Submitted by Charles Owens <owensc@enc.edu>, who said: "I made a minor (one-line) modification to chpass, with regards to whether or not it allows the changing of shells. In the 2.0.5 code, field changing follows the settings specified in the "list" structure defined in table.c . For the shell, though, this is ignored. A quick look in edit.c showed me why, but I don't understand why it was written as such. The logic was if shell is standard shell, allow changing I changed it to if shell changing is allowed (per table.c) and it is a standard shell OR if uid=0, then allow changing." Makes sense to me. - Update man page.
1996-02-23 16:08:59 +00:00
.It Fl d Ar domain
Specify what domain to use when changing an NIS password. By default,
.Nm passwd
assumes that the system default domain should be used. This flag is
primarily for use by the superuser on the NIS master server: a single
NIS server can support multiple domains. It is also possible that the
domainname on the NIS master may not be set (it is not necessary for
an NIS server to also be a client) in which case the
.Nm passwd
command needs to be told what domain to operate on.
.It Fl s Ar host
Specify the name of an NIS server. This option, in conjunction
with the
.Fl d
option, can be used to change an NIS password on a non-local NIS
server. When a domain is specified with the
.Fl d
option and
.Nm passwd
is unable to determine the name of the NIS master server (possibly because
the local domainname isn't set), the name of the NIS master is assumed to
be
.if t ``localhost''.
.if n "localhost".
This can be overidden with the
Merge in changes to support the new rpc.yppasswdd(8) and fix a few bugs. In passwd(1): - Gut most of yp_passwd.c and leave only a few things that aren't common to pw_yp.c. - Add support for -d and -h flags to select domains and NIS server hosts to use when updating NIS passwords. This allows passwd(1) to be used for changing NIS passwords from machines that aren't configured as NIS clients. (This is mostly to allow passwd(1) to work on NIS master servers that aren't configured as clients -- an NIS server need not necessarily be configured as a client itself.) NOTE: Realize that having the ability to specify a domain and hostname lets you use passwd(1) (and chpass(1) too) to submit update requests to yppasswd daemons running on remote servers in remote domains which you may not even be bound to. For example, my machine at home is not an NIS client of the servers on the network that I manage, yet I can easily change my password at work using my FreeBSD box at home by doing: 'passwd -d work.net.domain -h any.nis.server.on.my.net wpaul'. (Yes, I do use securenets at work; temporarily modified my securenets file to give my home system access.) Some people may not be too thrilled with this idea. Those who don't like this feature can recompile passwd(1) and chpass(1) with -DPARANOID to restrict the use of these flags to the superuser. (Oh, I should be adding proper securenets support to ypserv(8) and rpc.yppasswdd(8) over the weekend.) - Merge in changes to allow root on the NIS master server to bypass authentication and change any user's NIS password. (The super-user on the NIS master already has privileges to do this, but doing it through passwd(1) is much easier than updating the maps by hand.) Note that passwd(1) communicates with rpc.yppasswdd(8) via a UNIX domain socket instead of via standard RPC/IP in this case. - Update man page. In chpass(1): - Fix pw_yp.c to work properly in environments where NIS client services aren't available. - Use realloc() instead of malloc() in copy_yp_pass() and copy_local_pass(). - Fix silly bug in copy_yp_pass(); some of the members of the passwd structure weren't being filled in correctly. (This went unnoticed for a while since the old yppasswdd didn't allow changes to the fields that were being botched.) - chpass(1) now also allows the superuser on the NIS master server to make unrestricted changes to any user's NIS password information. - Use UNIX domain comm channel to rpc.yppasswdd(8) when run by the superuser on the NIS master. This allows several new things: o superuser can update an entire master.passwd.{byname,byuid} entry o superuser can update records in arbitrary domains using -d flag to select a domain (before you could only change the default domain) o superuser can _add_ records to the NIS master.passwd maps, provided rpc.yppasswdd(8) has been started with the -a flag (to do this, the superuser must force NIS operation by specifying the -y flag to chpass(1) along with -a, i.e. 'chpass -y -a 'foo:::::::::') - Back out the 'chpass -a <new password entry> breaks with NIS' fix from the last revision and fix it properly this time. The previous revision fixed the immediate problem but broke NIS operation in some cases. - In edit.c, be a little more reasonable about deciding when to prevent the shell field from being changed. Submitted by Charles Owens <owensc@enc.edu>, who said: "I made a minor (one-line) modification to chpass, with regards to whether or not it allows the changing of shells. In the 2.0.5 code, field changing follows the settings specified in the "list" structure defined in table.c . For the shell, though, this is ignored. A quick look in edit.c showed me why, but I don't understand why it was written as such. The logic was if shell is standard shell, allow changing I changed it to if shell changing is allowed (per table.c) and it is a standard shell OR if uid=0, then allow changing." Makes sense to me. - Update man page.
1996-02-23 16:08:59 +00:00
.Fl s
flag. The specified hostname need not be the name of an NIS master: the
name of the NIS master for a given map can be determined by querying any
NIS server (master or slave) in a domain, so specifying the name of a
slave server will work equally well.
.Pp
Merge in changes to support the new rpc.yppasswdd(8) and fix a few bugs. In passwd(1): - Gut most of yp_passwd.c and leave only a few things that aren't common to pw_yp.c. - Add support for -d and -h flags to select domains and NIS server hosts to use when updating NIS passwords. This allows passwd(1) to be used for changing NIS passwords from machines that aren't configured as NIS clients. (This is mostly to allow passwd(1) to work on NIS master servers that aren't configured as clients -- an NIS server need not necessarily be configured as a client itself.) NOTE: Realize that having the ability to specify a domain and hostname lets you use passwd(1) (and chpass(1) too) to submit update requests to yppasswd daemons running on remote servers in remote domains which you may not even be bound to. For example, my machine at home is not an NIS client of the servers on the network that I manage, yet I can easily change my password at work using my FreeBSD box at home by doing: 'passwd -d work.net.domain -h any.nis.server.on.my.net wpaul'. (Yes, I do use securenets at work; temporarily modified my securenets file to give my home system access.) Some people may not be too thrilled with this idea. Those who don't like this feature can recompile passwd(1) and chpass(1) with -DPARANOID to restrict the use of these flags to the superuser. (Oh, I should be adding proper securenets support to ypserv(8) and rpc.yppasswdd(8) over the weekend.) - Merge in changes to allow root on the NIS master server to bypass authentication and change any user's NIS password. (The super-user on the NIS master already has privileges to do this, but doing it through passwd(1) is much easier than updating the maps by hand.) Note that passwd(1) communicates with rpc.yppasswdd(8) via a UNIX domain socket instead of via standard RPC/IP in this case. - Update man page. In chpass(1): - Fix pw_yp.c to work properly in environments where NIS client services aren't available. - Use realloc() instead of malloc() in copy_yp_pass() and copy_local_pass(). - Fix silly bug in copy_yp_pass(); some of the members of the passwd structure weren't being filled in correctly. (This went unnoticed for a while since the old yppasswdd didn't allow changes to the fields that were being botched.) - chpass(1) now also allows the superuser on the NIS master server to make unrestricted changes to any user's NIS password information. - Use UNIX domain comm channel to rpc.yppasswdd(8) when run by the superuser on the NIS master. This allows several new things: o superuser can update an entire master.passwd.{byname,byuid} entry o superuser can update records in arbitrary domains using -d flag to select a domain (before you could only change the default domain) o superuser can _add_ records to the NIS master.passwd maps, provided rpc.yppasswdd(8) has been started with the -a flag (to do this, the superuser must force NIS operation by specifying the -y flag to chpass(1) along with -a, i.e. 'chpass -y -a 'foo:::::::::') - Back out the 'chpass -a <new password entry> breaks with NIS' fix from the last revision and fix it properly this time. The previous revision fixed the immediate problem but broke NIS operation in some cases. - In edit.c, be a little more reasonable about deciding when to prevent the shell field from being changed. Submitted by Charles Owens <owensc@enc.edu>, who said: "I made a minor (one-line) modification to chpass, with regards to whether or not it allows the changing of shells. In the 2.0.5 code, field changing follows the settings specified in the "list" structure defined in table.c . For the shell, though, this is ignored. A quick look in edit.c showed me why, but I don't understand why it was written as such. The logic was if shell is standard shell, allow changing I changed it to if shell changing is allowed (per table.c) and it is a standard shell OR if uid=0, then allow changing." Makes sense to me. - Update man page.
1996-02-23 16:08:59 +00:00
.It Fl o
Do not automatically override the password authentication checks for the
super-user on the NIS master server; assume 'old' mode instead. This
flag is of limited practical use but is useful for testing.
.El
1994-05-27 12:33:43 +00:00
.Sh FILES
.Bl -tag -width /etc/master.passwd -compact
.It Pa /etc/master.passwd
The user database
.It Pa /etc/passwd
A Version 7 format password file
.It Pa /etc/passwd.XXXXXX
Temporary copy of the password file
.It Pa /etc/login.conf
Login class capabilities database
.It Pa /etc/auth.conf
configure authentication services
1994-05-27 12:33:43 +00:00
.El
.Sh SEE ALSO
.Xr chpass 1 ,
.Xr kerberos 1 ,
.Xr kinit 1 ,
.Xr login 1 ,
.Xr login.conf 5 ,
1994-05-27 12:33:43 +00:00
.Xr passwd 5 ,
.Xr kpasswdd 8 ,
.Xr pwd_mkdb 8 ,
.Xr vipw 8
.Rs
.%A Robert Morris
.%A Ken Thompson
.%T "UNIX password security"
.Re
.Sh NOTES
The
.Xr yppasswd 1
command is really only a link to
.Nm passwd .
1994-05-27 12:33:43 +00:00
.Sh HISTORY
A
.Nm passwd
command appeared in
.At v6 .