GETPWENT(3) BSD Library Functions Manual GETPWENT(3)

NAME
     ggeettppwweenntt, ggeettppwwnnaamm, ggeettppwwuuiidd, sseettppaasssseenntt, sseettppwweenntt, eennddppwweenntt - password
     database operations

LLIIBBRRAARRYY
     Standard C Library (libc, -lc)

SYNOPSIS
     ##iinncclluuddee <>
     ##iinncclluuddee <>

     struct passwd *
     ggeettppwweenntt(void);

     struct passwd *
     ggeettppwwnnaamm(const char *login);

     struct passwd *
     ggeettppwwuuiidd(uidt uid);

     int
     sseettppaasssseenntt(int stayopen);

     int
     sseettppwweenntt(void);

     void
     eennddppwweenntt(void);

DESCRIPTION
     These functions operate on the password database file which is described
     in passwd(5).  Each entry in the database is defined by the structure
     passwd found in the include file :

           struct passwd {
                   char    *pwname;       /* user name */
                   char    *pwpasswd;     /* encrypted password */
                   uidt   pwuid;         /* user uid */
                   gidt   pwgid;         /* user gid */
                   timet  pwchange;      /* password change time */
                   char    *pwclass;      /* user access class */
                   char    *pwgecos;      /* Honeywell login info */
                   char    *pwdir;        /* home directory */
                   char    *pwshell;      /* default shell */
                   timet  pwexpire;      /* account expiration */
                   int     pwfields;      /* internal: fields filled in */
           };

     The functions ggeettppwwnnaamm() and ggeettppwwuuiidd() search the password database for
     the given login name or user uid, respectively, always returning the
     first one encountered.

     The ggeettppwweenntt() function sequentially reads the password database and is
     intended for programs that wish to process the complete list of users.

     The sseettppaasssseenntt() function accomplishes two purposes.  First, it causes
     ggeettppwweenntt() to ``rewind'' to the beginning of the database.  Additionally,
     if stayopen is non-zero, file descriptors are left open, significantly
     speeding up subsequent accesses for all of the routines.  (This latter
     functionality is unnecessary for ggeettppwweenntt() as it doesn't close its file
     descriptors by default.)

     It is dangerous for long-running programs to keep the file descriptors
     open as the database will become out of date if it is updated while the
     program is running.

     The sseettppwweenntt() function is identical to sseettppaasssseenntt() with an argument of
     zero.

     The eennddppwweenntt() function closes any open files.

     As of Mac OS X 10.3, there are now different per-user behaviours of this
     function, based on the AuthenticationAuthority value stored for the
     queried user in DirectoryServices.

     If the queried user is still a legacy crypt password user or now has an
     AuthenticationAuthority value containing ``;basic;'', these routines will
     behave in their standard BSD fashion.  These functions will ``shadow''
     the password file, e.g. allow only certain programs to have access to the
     encrypted password.  If the process which calls them has an effective uid
     of 0, the encrypted password will be returned, otherwise, the password
     field of the returned structure will point to the string `*'.

     By default in Mac OS X 10.3 and later all users will have an Authentica-
     tionAuthority with the value ``;ShadowHash;''.  These users will have a
     visible password value of ``********''.  These functions will have no
     access to the encrypted password whatsoever.  Setting or changing an user
     password must be done entirely through the DirectoryService APIs for this
     default user.

     There also exists an ``Apple Password Server'' user whose password value
     is also ``********'' and with an AuthenticationAuthority that contains
     the value ";ApplePasswordServer;" among other data.  There is no getpwnam
     access to the password for this user either and again set/change password
     can be done through the DirectoryService API.

     Finally in support of local user caching there is a local cached user
     whose password is also ``********'' and has an AuthenticationAuthority
     value containing ``;LocalCachedUser;'' among other data.  These functions
     also provide no access to the password for this user and set/change pass-
     word functionality is through the DirectoryService API.

RETURN VALUES
     The functions ggeettppwweenntt(), ggeettppwwnnaamm(), and ggeettppwwuuiidd(), return a valid
     pointer to a passwd structure on success and a null pointer if end-of-
     file is reached or an error occurs.  The sseettppaasssseenntt() and sseettppwweenntt()
     functions return 0 on failure and 1 on success.  The eennddppwweenntt() function
     has no return value.

FILES     /etc/pwd.db         The insecure password database file
     /etc/spwd.db        The secure password database file
     /etc/master.passwd  The current password file
     /etc/passwd         A Version 7 format password file

SEE ALSO
     getlogin(2), getgrent(3), yp(4), passwd(5), pwdmkdb(8), vipw(8)

HISTORY
     The ggeettppwweenntt(), ggeettppwwnnaamm(), ggeettppwwuuiidd(), sseettppwweenntt(), and eennddppwweenntt() func-
     tions appeared in Version 7 AT&T UNIX.  The sseettppaasssseenntt() function
     appeared in 4.3BSD-Reno.

CCOOMMPPAATTIIBBIILLIITTYY
     The historic function setpwfile(3), which allowed the specification of
     alternate password databases, has been deprecated and is no longer avail-
     able.

BUGS
     The functions ggeettppwweenntt(), ggeettppwwnnaamm(), and ggeettppwwuuiidd(), leave their results
     in an internal static object and return a pointer to that object.  Subse-
     quent calls to the same function will modify the same object.

     The functions ggeettppwweenntt(), eennddppwweenntt(), sseettppaasssseenntt(), and sseettppwweenntt() are
     fairly useless in a networked environment and should be avoided, if pos-
     sible.

BSD                           September 20, 1994                           BSD