CHPASS(1)

πŸ“¦
version 1042.100.6.0.1 Β· 3 versions
, in nixpkgs unstable

πŸŽ€ CHPASS(1) β€” the add-or-change-user-database-info page, bestie edition πŸŽ€

Okay so this is chpass, plus its two ride-or-die aliases chfn and chsh β€” from the General Commands Manual, one of those classic Unix pages. Let's get into it πŸ’…


✨ NAME ✨

chpass, chfn, chsh β€” add or change user database information 🫢


✨ SYNOPSIS ✨

chpass [-l location] [-u authname] [-s newshell] [user]

✨ DESCRIPTION ✨

So the chpass utility literally lets you edit the user database info associated with user β€” or, if you don't hand it a user, it just does the current user by default. Iconic default behavior, honestly πŸ’–

🚨 Big warning bestie: chpass cannot change the user's password on Open Directory systems. Use the passwd(1) utility for that instead. Not me telling you twice, but like, I'm telling you twice.

The chfn and chsh utilities behave identically to chpass. And like... there's genuinely only one program. (There is only one program.) Main character shared-identity energy πŸ‘‘

So here's the vibe: the information gets formatted and handed off to an editor for changes. Only the info that the user is actually allowed to change gets displayed. No sneaking a peek at stuff you can't touch πŸ”’

The options are as follows:

  • -l location β€” If not specified, chpass will perform a search for the user record on all available Open Directory nodes. When you do specify it, chpass will edit the user record on the directory node at the given location. So basically: leave it off and it goes hunting everywhere 🌸
  • -u authname β€” The user name to use when authenticating to the directory node containing the user. Your "hi it's me, let me in" name πŸͺͺ
  • -s newshell β€” Attempt to change the user's shell to newshell. Simple as that ✨

πŸ¦‹ the display items πŸ¦‹

Possible display items are as follows:

Login:              user's login name
Uid:                user's login
Gid:                user's login group
Generated uid:      user's UUID
Full Name:          user's real name
Office Location:    user's office location
Office Phone:       user's office phone
Home Phone:         user's home phone
Home Directory:     user's home directory
Shell:              user's login shell

Okay now let's break each of these down, because they all matter πŸ‘‡

The login field is the user name used to access the computer account.

The uid field is the number associated with the login field. Both of these fields should be unique across the system (and often across a group of systems) β€” because they literally control file access. So like, don't be sloppy with these, fr fr πŸ”₯

πŸ’€ While it is possible to have multiple entries with identical login names and/or identical user id's, it is usually a mistake to do so. Routines that manipulate these files will often return only one of the multiple entries β€” and that one by random selection. So the vibe check fails and you get chaos. Don't do it.

The gid field is the group that the user will be placed in at login. Since BSD supports multiple groups (see groups(1)), this field currently has little special meaning. This field may be filled in with either a number or a group name (see group(5)).

The generated uid field is the globally unique identifier (UUID) for the user. The full name field contains the full name of the user. Very demure, very mindful πŸŽ€

The user's home directory is the full Unix path name where the user will be placed at login.

The shell field is the command interpreter the user prefers. If the shell field is empty, the Bourne shell, /bin/sh, is assumed ✨ And here's the caveat: when altering a login shell, and not the super-user, the user may not change from a non-standard shell or to a non-standard shell. "Non-standard" is defined as a shell not found in /etc/shells. So like, stay in the approved list or the vibes will not be immaculate πŸ™ˆ

The picture field is the path to a picture to be displayed for the user. Cute πŸ–ΌοΈ


🌈 OPEN DIRECTORY 🌈

User database entries are under the control of DirectoryService(8) and may be physically located in many different places, including the local Directory Service node, and remote LDAP servers. This version of chpass uses Open Directory to change user database information. It does not interact with the historic flat file database /etc/master.passwd 🫢

πŸ‘‘ Read that again β€” chpass here is an Open Directory girlie. The old flat file database is not invited to this party.

πŸ’œ ENVIRONMENT πŸ’œ

The vi(1) editor will be used unless the environment variable EDITOR is set to an alternate editor. When the editor terminates, the information is re-read and used to update the user database itself. Only the user, or the super-user, may edit the information associated with the user πŸ”


πŸ“ FILES πŸ“

/etc/chpass.XXXXXX  temporary file
/etc/shells         the list of approved shells

⭐ EXAMPLES ⭐

Change the shell of the current user to /bin/zsh:

chsh -s /bin/zsh

That's it. That's the whole example. Slay ✨


πŸ’– SEE ALSO πŸ’–

login(1), passwd(1), getusershell(3), DirectoryService(8)

Robert Morris and Ken Thompson, UNIX Password security.


🌸 HISTORY 🌸

The chpass utility appeared in 4.3BSD-Reno. Old money, honestly πŸŽ€


Okay bestie that's the whole page β€” Debian, May 25, 2021, version of the chpass manual page. Go forth and edit your user database info responsibly πŸ’…βœ¨

πŸ“¦ where this page comes from