From cbec586dc12d3cc597535e3aa49819c9ab39d40c Mon Sep 17 00:00:00 2001
From: Dante Catalfamo
Date: Mon, 29 Jun 2020 17:21:16 -0400
Subject: Indent heading contents, more content

---
 .../posts/how-bsd-authentication-works/index.org   | 545 +++++++++++----------
 1 file changed, 275 insertions(+), 270 deletions(-)

diff --git a/content/posts/how-bsd-authentication-works/index.org b/content/posts/how-bsd-authentication-works/index.org
index 6eae6a5..76fe4a4 100644
--- a/content/posts/how-bsd-authentication-works/index.org
+++ b/content/posts/how-bsd-authentication-works/index.org
@@ -10,303 +10,308 @@
 
 [[https://web.archive.org/web/20170327150148/http://www.penzin.net/bsdauth/]]
 * History
-OpenBSD is quite different from many other Unix-like operating systems
-in many ways, but one way which I find interesting is the
-authentication system. Most systems from AIX, Solaris, and Linux to
-most BSDs including MacOS use some form of a system called Pluggable
-Authentication Module (PAM). The two main implementations of PAM are
-[[http://www.linux-pam.org/][Linux PAM]] and [[https://www.openpam.org/][OpenPAM]]. PAM modules are created a dynamically loaded
-shared objects, which communicate using a set of standard
-interfaces ([[https://linux.die.net/man/3/pam][Linux-PAM]]) ([[https://www.freebsd.org/cgi/man.cgi?query=pam&apropos=0&sektion=3&manpath=FreeBSD+12.1-RELEASE+and+Ports&arch=default&format=html][OpenPAM]]). PAM is configured using the [[https://linux.die.net/man/5/pam.d][pam.d]]
-directory and [[https://www.freebsd.org/cgi/man.cgi?query=pam.conf&sektion=5&apropos=0&manpath=FreeBSD+12.1-RELEASE+and+Ports][pam.conf]].
-
-OpenBSD on the other hand uses a mechanism called BSD
-Authentication. It was originally developed for a proprietary
-operating system called [[https://en.wikipedia.org/wiki/BSD/OS][BSD/OS]] by [[https://en.wikipedia.org/wiki/Berkeley_Software_Design][Berkeley Software Design Inc.]], who
-later donated the system. It was adopted by OpenBSD in release
-2.9. BSD Auth is comparatively much simpler than PAM. Modules or,
-authentication "styles", are instead stand alone applications or
-scripts that communicate over IPC (=PF_LOCAL, SOCK_STREAM=,
-specifically). The program or script has no ability to interfere with
-the parent and can very easily revoke permissions using =pledge(3)= or
-=unveil(3)=.
+
+  OpenBSD is quite different from many other Unix-like operating systems
+  in many ways, but one way which I find interesting is the
+  authentication system. Most systems from AIX, Solaris, and Linux to
+  most BSDs including MacOS use some form of a system called Pluggable
+  Authentication Module (PAM). The two main implementations of PAM are
+  [[http://www.linux-pam.org/][Linux PAM]] and [[https://www.openpam.org/][OpenPAM]]. PAM modules are created a dynamically loaded
+  shared objects, which communicate using a set of standard
+  interfaces ([[https://linux.die.net/man/3/pam][Linux-PAM]]) ([[https://www.freebsd.org/cgi/man.cgi?query=pam&apropos=0&sektion=3&manpath=FreeBSD+12.1-RELEASE+and+Ports&arch=default&format=html][OpenPAM]]). PAM is configured using the [[https://linux.die.net/man/5/pam.d][pam.d]]
+  directory and [[https://www.freebsd.org/cgi/man.cgi?query=pam.conf&sektion=5&apropos=0&manpath=FreeBSD+12.1-RELEASE+and+Ports][pam.conf]].
+
+  OpenBSD on the other hand uses a mechanism called BSD
+  Authentication. It was originally developed for a proprietary
+  operating system called [[https://en.wikipedia.org/wiki/BSD/OS][BSD/OS]] by [[https://en.wikipedia.org/wiki/Berkeley_Software_Design][Berkeley Software Design Inc.]], who
+  later donated the system. It was adopted by OpenBSD in release
+  2.9. BSD Auth is comparatively much simpler than PAM. Modules or,
+  authentication "styles", are instead stand alone applications or
+  scripts that communicate over IPC (=PF_LOCAL, SOCK_STREAM=,
+  specifically). The program or script has no ability to interfere with
+  the parent and can very easily revoke permissions using =pledge(3)= or
+  =unveil(3)=.
 
 * Why
-This one is pretty difficult, since there seems to be very little
-information about how BSD Auth works apart from the source code
-itself. This is my best attempt to understand the flow of BSD Auth
-from what I've read.
 
+  This one is pretty difficult, since there seems to be very little
+  information about how BSD Auth works apart from the source code
+  itself. This is my best attempt to understand the flow of BSD Auth
+  from what I've read.
 
 * BSD Auth Modules
-These programs or scripts are located in =/usr/libexec/auth/= with the
-naming convention =login_<style>=. They take arguments in the form of
-
-#+BEGIN_SRC shell
-login_<style> [-s service] [-v key=value] user [class]
-#+END_SRC
 
-- =<style>= is the authentication method. This could be =passwd=,
-  =radius=, =skey=, =yubikey=, etc.
-  - There's more information about available styles in =login.conf(5)=
-- =service= is the service type. Typically authentication methods will
-  accept three values here, =login=, =challenge=, or =response=. Some
-  styles take different service arguments, read the style's man page
-  for details.
-  - =login= is typically the default method
-- =-v key=value= is an optional argument. This is used to pass extra
-  data to the program under certain circumstances.
-- =user= is the name of the user to be authenticated.
-- =class= is optional and specifies the class of the user to be
-  authenticated.
+  These programs or scripts are located in =/usr/libexec/auth/= with the
+  naming convention =login_<style>=. They take arguments in the form of
+
+  #+BEGIN_SRC shell
+  login_<style> [-s service] [-v key=value] user [class]
+  #+END_SRC
+
+  - =<style>= is the authentication method. This could be =passwd=,
+    =radius=, =skey=, =yubikey=, etc. There's more information about
+    available styles in =login.conf(5)= under the =AUTHENTICATION=
+    header.
+  - =service= is the service type. Typically authentication methods will
+    accept one of three values here, =login=, =challenge=, or
+    =response=. =login= is the default if it's not specified, and is
+    usually the right choice. Read the style's man page for details.
+  - =-v key=value= is an optional argument. This is used to pass extra
+    data to the program under certain circumstances.
+  - =user= is the name of the user to be authenticated.
+  - =class= is optional and specifies the class of the user to be
+    authenticated.
 
 * Documentation
-All of the high level authentication functions are described in
-=authenticate(3)=, with the lower level functions being described in
-=auth_subr(3)=.
 
-* auth_userokay
-The highest level function, and easiest to use is =auth_userokay=. It
-takes four character arrays as arguments, =name=, =style=, =type=, and
-=password=. It returns either a =0= for failure, of a non-zero value
-for success.
+  All of the high level authentication functions are described in
+  =authenticate(3)=, with the lower level functions being described in
+  =auth_subr(3)=.
 
-This function lives inside =/lib/libc/gen/authenticate.c=
-
-#+BEGIN_SRC c
-int auth_userokay(char *name, char *style, char *type, char *password);
-#+END_SRC
+* auth_userokay
 
-- =name= is the name of the user to be authenticated
-- =style= is the login method to be used
-  - If =style= is =NULL=, the user's default login style will be
-    used. By default this is =passwd= on normal accounts.
-  - The style can be one of the installed authentication methods, like
-    =passwd=, =radius=, =skey=, =yubikey=, etc.
-  - There's more information about available styles in =login.conf(5)=
-  - Styles can also be installed through BSD Auth module packages
-- =type= is the authentication type
-  - Types are defined in =login.conf= and define a group of allowed
-    auth styles
-  - If =type= is =NULL=, use the auth type for the user's login
-    class. The default type is =auth-default=, which allows
-    =psaswd= and =skey= auth methods.
-  - There's more information about how to add methods in =login.conf(5)=
-- =password= is the password to test
-  - If =password= is =NULL=, then the user is interactively
-    prompted. This is required for auth styles using
-    challenge-response methods.
-  - If =password= is specified, then it's non-interactively tested
-
-=auth_userokay= is just a wrapper around =auth_usercheck=, which
-returns a finished auth session of type =auth_session_t=. It closes
-the auth session using =auth_close= and returns the value returned
-from closing.
+  The highest level function, and easiest to use is =auth_userokay=. It
+  takes four character arrays as arguments, =name=, =style=, =type=, and
+  =password=. It returns either a =0= for failure, of a non-zero value
+  for success.
+
+  This function lives inside =/lib/libc/gen/authenticate.c=
+
+  #+BEGIN_SRC c
+  int auth_userokay(char *name, char *style, char *type, char *password);
+  #+END_SRC
+
+  - =name= is the name of the user to be authenticated
+  - =style= is the login method to be used
+    - If =style= is =NULL=, the user's default login style will be
+      used. By default this is =passwd= on normal accounts.
+    - The style can be one of the installed authentication methods, like
+      =passwd=, =radius=, =skey=, =yubikey=, etc.
+    - There's more information about available styles in =login.conf(5)=
+    - Styles can also be installed through BSD Auth module packages
+  - =type= is the authentication type
+    - Types are defined in =login.conf= and define a group of allowed
+      auth styles
+    - If =type= is =NULL=, use the auth type for the user's login
+      class. The default type is =auth-default=, which allows
+      =psaswd= and =skey= auth methods.
+    - There's more information about how to add methods in =login.conf(5)=
+  - =password= is the password to test
+    - If =password= is =NULL=, then the user is interactively
+      prompted. This is required for auth styles using
+      challenge-response methods.
+    - If =password= is specified, then it's non-interactively tested
+
+  =auth_userokay= is just a wrapper around =auth_usercheck=, which
+  returns a finished auth session of type =auth_session_t=. It closes
+  the auth session using =auth_close= and returns the value returned
+  from closing.
 
 * auth_session_t
 
-#+BEGIN_SRC c
-struct auth_session_t {
-    char    *name;                 /* name of use being authenticated */
-    char    *style;                /* style of authentication used */
-    char    *class;                /* class of user */
-    char    *service;              /* type of service being performed */
-    char    *challenge;            /* last challenge issued */
-    int     flags;                 /* see below */
-    struct  passwd *pwd;           /* password entry for user */
-    struct  timeval now;           /* time of authentication */
-
-    int     state;                 /* authenticated state */
-
-    struct  rmfiles *rmlist;       /* list of files to remove on failure */
-    struct  authopts *optlist;     /* list of options to scripts */
-    struct  authdata *data;        /* additional data to send to scripts */
-
-    char    spool[MAXSPOOLSIZE];   /* data returned from login script */
-    int     index;                 /* how much returned thus far */
-
-    int     fd;                    /* connection to authenticator */
-
-    va_list ap0;                   /* argument list to auth_call */
-    va_list ap;                    /* additional arguments to auth_call */
-};
-#+END_SRC
-
-Where =authdata=, =authopts=, and =rmfiles= are defined as
-
-#+BEGIN_SRC c
-struct rmfiles {
-    struct rmfiles  *next;
-    char            *file;
-};
-
-struct authopts {
-    struct authopts *next;
-    char            *opt;
-};
-
-struct authdata {
-    struct  authdata *next;
-    void    *ptr;
-    size_t   len;
-};
-#+END_SRC
+  #+BEGIN_SRC c
+  struct auth_session_t {
+      char    *name;                 /* name of use being authenticated */
+      char    *style;                /* style of authentication used */
+      char    *class;                /* class of user */
+      char    *service;              /* type of service being performed */
+      char    *challenge;            /* last challenge issued */
+      int     flags;                 /* see below */
+      struct  passwd *pwd;           /* password entry for user */
+      struct  timeval now;           /* time of authentication */
+
+      int     state;                 /* authenticated state */
+
+      struct  rmfiles *rmlist;       /* list of files to remove on failure */
+      struct  authopts *optlist;     /* list of options to scripts */
+      struct  authdata *data;        /* additional data to send to scripts */
+
+      char    spool[MAXSPOOLSIZE];   /* data returned from login script */
+      int     index;                 /* how much returned thus far */
+
+      int     fd;                    /* connection to authenticator */
+
+      va_list ap0;                   /* argument list to auth_call */
+      va_list ap;                    /* additional arguments to auth_call */
+  };
+  #+END_SRC
+
+  Where =authdata=, =authopts=, and =rmfiles= are defined as
+
+  #+BEGIN_SRC c
+  struct rmfiles {
+      struct rmfiles  *next;
+      char            *file;
+  };
+
+  struct authopts {
+      struct authopts *next;
+      char            *opt;
+  };
+
+  struct authdata {
+      struct  authdata *next;
+      void    *ptr;
+      size_t   len;
+  };
+  #+END_SRC
 
 * auth_usercheck
-#+BEGIN_SRC c
-auth_session_t *auth_usercheck(char *name, char *style, char *type, char *password)
-#+END_SRC
-
-=auth_usercheck= checks the user name against the passwd db. It also
-checks the login class against the =login.conf= db, along with
-confirming the login styles available.
-
-If the password is non-=NULL=, then it calls =auth_open=, which
-allocates and returns the pointer to an =auth_session_t=, and sets its
-default =service= to =login=, and it's =fd= to =-1=. After that's
-returned, =auth_usercheck= calls (with =as= as the session struct)
 
-#+BEGIN_SRC c
-auth_setitem(as, AUTHV_SERVICE, "response");
-auth_setdata(as, "", 1);
-auth_setdata(as, password, strlen(password) + 1);
-#+END_SRC
-
-setting the service protocol to =response=, adding an empty line to
-the session data, then adding the password as data. If the password is
-=NULL=, it sets the =auth_session_t= pointer to =NULL=. It then passes
-the user name, style, login class, and =NULL= char pointer to
-=auth_verify=. The last two variables are received as variable
-arguments. It then returns the auth session pointer the call
-returns.
+  #+BEGIN_SRC c
+  auth_session_t *auth_usercheck(char *name, char *style, char *type, char *password)
+  #+END_SRC
+
+  =auth_usercheck= checks the user name against the passwd db. It also
+  checks the login class against the =login.conf= db, along with
+  confirming the login styles available.
+
+  If the password is non-=NULL=, then it calls =auth_open=, which
+  allocates and returns the pointer to an =auth_session_t=, and sets its
+  default =service= to =login=, and it's =fd= to =-1=. After that's
+  returned, =auth_usercheck= calls (with =as= as the session struct)
+
+  #+BEGIN_SRC c
+  auth_setitem(as, AUTHV_SERVICE, "response");
+  auth_setdata(as, "", 1);
+  auth_setdata(as, password, strlen(password) + 1);
+  #+END_SRC
+
+  setting the service protocol to =response=, adding an empty line to
+  the session data, then adding the password as data. If the password is
+  =NULL=, it sets the =auth_session_t= pointer to =NULL=. It then passes
+  the user name, style, login class, and =NULL= char pointer to
+  =auth_verify=. The last two variables are received as variable
+  arguments. It then returns the auth session pointer the call
+  returns.
 
 * auth_verify
 
-#+BEGIN_SRC c
-auth_session_t *auth_verify(auth_session_t *as, char *style, char *name, ...)
-#+END_SRC
+  #+BEGIN_SRC c
+  auth_session_t *auth_verify(auth_session_t *as, char *style, char *name, ...)
+  #+END_SRC
 
-=auth_verify= creates an auth session if =as= is =NULL=. It then sets
-the user name and style of the session, if the respective arguments
-are non-=NULL=. It then copies its variable arguments to the auth
-session's =va_list ap=, which is used inside of =auth_call=.
+  =auth_verify= creates an auth session if =as= is =NULL=. It then sets
+  the user name and style of the session, if the respective arguments
+  are non-=NULL=. It then copies its variable arguments to the auth
+  session's =va_list ap=, which is used inside of =auth_call=.
 
-After that it constructs the path of the authentication module by
-combining =_PATH_AUTHPROG=, which is defined in =login_cap.h= as
-=/usr/libexec/auth/login_=, and the authentication style. For the
-case of auth style =passwd=, it would result in the path
-=/usr/libexec/auth/login_passwd=.
+  After that it constructs the path of the authentication module by
+  combining =_PATH_AUTHPROG=, which is defined in =login_cap.h= as
+  =/usr/libexec/auth/login_=, and the authentication style. For the
+  case of auth style =passwd=, it would result in the path
+  =/usr/libexec/auth/login_passwd=.
 
-Then =auth_call= is called with the struct, the path to the auth
-module, the auth style, the "-s" flag followed by the service (login,
-challenge, response), a double dash, the user name, and a =NULL=
-character pointer. The return value of =auth_call= is ignored and a
-pointer to the auth session is returned immediately afterwards.
+  Then =auth_call= is called with the struct, the path to the auth
+  module, the auth style, the "-s" flag followed by the service (login,
+  challenge, response), a double dash, the user name, and a =NULL=
+  character pointer. The return value of =auth_call= is ignored and a
+  pointer to the auth session is returned immediately afterwards.
 
-#+BEGIN_SRC c
-auth_call(as, path, auth_getitem(as, AUTHV_STYLE), "-s",
-    auth_getitem(as, AUTHV_SERVICE), "--", name, (char *)NULL);
-#+END_SRC
+  #+BEGIN_SRC c
+  auth_call(as, path, auth_getitem(as, AUTHV_STYLE), "-s",
+      auth_getitem(as, AUTHV_SERVICE), "--", name, (char *)NULL);
+  #+END_SRC
 
 * auth_call
 
-#+BEGIN_SRC c
-int auth_call(auth_session_t *as, char *path, ...)
-#+END_SRC
-
-<<here>>
-
----
-note: In the man page auth_subr it says
-#+begin_quote
-path    The full path name of the login script to run.  The call will
-             fail if path does not pass the requirements of the secure_path(3)
-             function.
-#+end_quote
-However I don't see this enforced anywhere, I even wrote a small test
-script to prove that's the case on =vfwall ~/authtest=.
-
-The manpage also says the path is limited to =/bin/= and =/usr/bin=,
-which is also not the case.
-
-Ask jcs about the file descriptor situation, I don't understand it
-after reading both the man page and source.
----
-
-Inside of =auth_call=, a socket pair of type =PF_LOCAL, SOCK_STREAM=
-is created. This is called the "back channel", and is used to
-communicate with the authentication module. The process then forks,
-calling ~execve(path, argv, auth_environ)~, where the =argv= is
-everything after =path= in the =auth_call= arguments. Any =authopts=
-set in the auth session are also passed as arguments in the format =-v
-opt1 -v opt2 -v opt3=, etc. =auth_environ= is defined at the top of
-the file as
-
-#+BEGIN_SRC c
-static char *auth_environ[] = {
-    "PATH=" _PATH_DEFPATH,
-    "SHELL=" _PATH_BSHELL,
-    NULL,
-};
-#+END_SRC
-
-Where both constants are defined in =paths.h= as
-
-#+BEGIN_SRC c
-#define	_PATH_DEFPATH	"/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin"
-#define	_PATH_BSHELL	"/bin/sh"
-#+END_SRC
-
-
-The =exec='d process then listens on FD 3, which is one half of the
-=sockpair= that was created earlier.
-
-In the non-exec'd process, first the contents of the auth session's
-=*data= are read in one at a time.
-
-The data received through the back channel is then put into the
-=spool= of the auth session using =_auth_spool(as, pfd[0])=. After
-that the spooled data is scanned for key words defined in
-=login_cap.h=.
-
-#+BEGIN_SRC c
-#define BI_AUTH         "authorize"         /* Accepted authentication */
-#define BI_REJECT       "reject"            /* Rejected authentication */
-#define BI_CHALLENGE    "reject challenge"  /* Reject with a challenge */
-#define BI_SILENT       "reject silent"     /* Reject silently */
-#define BI_REMOVE       "remove"            /* remove file on error */
-#define BI_ROOTOKAY     "authorize root"    /* root authenticated */
-#define BI_SECURE       "authorize secure"  /* okay on non-secure line */
-#define BI_SETENV       "setenv"            /* set environment variable */
-#define BI_UNSETENV     "unsetenv"          /* unset environment variable */
-#define BI_VALUE        "value"             /* set local variable */
-#define BI_EXPIRED      "reject expired"    /* account expired */
-#define BI_PWEXPIRED    "reject pwexpired"  /* password expired */
-#define BI_FDPASS       "fd"                /* child is passing an fd */
-#+END_SRC
-
-It is looking for lines that start with either =BI_AUTH=
-(=authorize=), or =BI_REJECT= (=reject=). If the line is still longer,
-it continues to scan for any other qualifiers such as =pwexpired= or
-=silent=. The struct's =state= is set to one using the =AUTH_= values
-from =login_cap.h= accordingly.
-
-#+BEGIN_SRC c
-/*
- * bits which can be returned by authenticate()/auth_scan()
- */
-#define  AUTH_OKAY       0x01            /* user authenticated */
-#define  AUTH_ROOTOKAY   0x02            /* authenticated as root */
-#define  AUTH_SECURE     0x04            /* secure login */
-#define  AUTH_SILENT     0x08            /* silent rejection */
-#define  AUTH_CHALLENGE  0x10            /* a challenge was given */
-#define  AUTH_EXPIRED    0x20            /* account expired */
-#define  AUTH_PWEXPIRED  0x40            /* password expired */
-#+END_SRC
-
-
-This is the integer returned by
-=auth_userokay=.
+  #+BEGIN_SRC c
+  int auth_call(auth_session_t *as, char *path, ...)
+  #+END_SRC
+
+  <<here>>
+
+  ---
+  note: In the man page auth_subr it says
+  #+begin_quote
+  path    The full path name of the login script to run.  The call will
+               fail if path does not pass the requirements of the secure_path(3)
+               function.
+  #+end_quote
+  However I don't see this enforced anywhere, I even wrote a small test
+  script to prove that's the case on =vfwall ~/authtest=.
+
+  The manpage also says the path is limited to =/bin/= and =/usr/bin=,
+  which is also not the case.
+
+  Ask jcs about the file descriptor situation, I don't understand it
+  after reading both the man page and source.
+  ---
+
+  Inside of =auth_call=, a socket pair of type =PF_LOCAL, SOCK_STREAM=
+  is created. This is called the "back channel", and is used to
+  communicate with the authentication module. The process then forks,
+  calling ~execve(path, argv, auth_environ)~, where the =argv= is
+  everything after =path= in the =auth_call= arguments. Any =authopts=
+  set in the auth session are also passed as arguments in the format =-v
+  opt1 -v opt2 -v opt3=, etc. =auth_environ= is defined at the top of
+  the file as
+
+  #+BEGIN_SRC c
+  static char *auth_environ[] = {
+      "PATH=" _PATH_DEFPATH,
+      "SHELL=" _PATH_BSHELL,
+      NULL,
+  };
+  #+END_SRC
+
+  Where both constants are defined in =paths.h= as
+
+  #+BEGIN_SRC c
+  #define	_PATH_DEFPATH	"/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin"
+  #define	_PATH_BSHELL	"/bin/sh"
+  #+END_SRC
+
+
+  The =exec='d process then listens on FD 3, which is one half of the
+  =sockpair= that was created earlier.
+
+  In the non-exec'd process, first the contents of the auth session's
+  =*data= are read in one at a time.
+
+  The data received through the back channel is then put into the
+  =spool= of the auth session using =_auth_spool(as, pfd[0])=. After
+  that the spooled data is scanned for key words defined in
+  =login_cap.h=.
+
+  #+BEGIN_SRC c
+  #define BI_AUTH         "authorize"         /* Accepted authentication */
+  #define BI_REJECT       "reject"            /* Rejected authentication */
+  #define BI_CHALLENGE    "reject challenge"  /* Reject with a challenge */
+  #define BI_SILENT       "reject silent"     /* Reject silently */
+  #define BI_REMOVE       "remove"            /* remove file on error */
+  #define BI_ROOTOKAY     "authorize root"    /* root authenticated */
+  #define BI_SECURE       "authorize secure"  /* okay on non-secure line */
+  #define BI_SETENV       "setenv"            /* set environment variable */
+  #define BI_UNSETENV     "unsetenv"          /* unset environment variable */
+  #define BI_VALUE        "value"             /* set local variable */
+  #define BI_EXPIRED      "reject expired"    /* account expired */
+  #define BI_PWEXPIRED    "reject pwexpired"  /* password expired */
+  #define BI_FDPASS       "fd"                /* child is passing an fd */
+  #+END_SRC
+
+  It is looking for lines that start with either =BI_AUTH=
+  (=authorize=), or =BI_REJECT= (=reject=). If the line is still longer,
+  it continues to scan for any other qualifiers such as =pwexpired= or
+  =silent=. The struct's =state= is set to one using the =AUTH_= values
+  from =login_cap.h= accordingly.
+
+  #+BEGIN_SRC c
+  /*
+   * bits which can be returned by authenticate()/auth_scan()
+   */
+  #define  AUTH_OKAY       0x01            /* user authenticated */
+  #define  AUTH_ROOTOKAY   0x02            /* authenticated as root */
+  #define  AUTH_SECURE     0x04            /* secure login */
+  #define  AUTH_SILENT     0x08            /* silent rejection */
+  #define  AUTH_CHALLENGE  0x10            /* a challenge was given */
+  #define  AUTH_EXPIRED    0x20            /* account expired */
+  #define  AUTH_PWEXPIRED  0x40            /* password expired */
+  #+END_SRC
+
+
+  This is the integer returned by
+  =auth_userokay=.
 
 * grapgh?
 # Setting env on auth_close(as)
-- 
cgit v1.2.3