[Otpasswd-talk] More observations

[Hannes Beinert]

A few more observations:

1. What would you think about moving the --flag list functionality to
a primary command-line option?  It seems to me that (-l, --list, or
perhaps --info, -i) would be more intuitive for a user to obtain
information about his user state.  The "list" functionality isn't
really a "flag", per se.

2. When changing a password with the -p option, I can see why it is
considered an error when no argument is supplied, however instead of
spitting out the entire help text, what about a short usage or simple
error?

3. When a password is successfully changed, the user state is
(partially) displayed.  How about only doing this if the -v option is
specified?  I kind of like the interface to the passwd command -- just
do it, and go away.  :-)

4. How does the code handle the situation where there is no static
password?  Is there now no password on all that functionality, or is
that functionality no longer accessible to the user?

5. I think there *might* be some value in having an
enforce/noenforce-type option available for the pam_otpasswd module.
I realize this can be specified as a policy, however I could see that
a system admin might feel good about having it hard-coded in the PAM
config so that this option could not be changed by a compromised or
corrupted configuration.  My thought is also that if a "noenforce"
override is applied to the pam_otpasswd line, then it could almost be
included in PAM configs by default.  No harm would be done if the
system were not completely configured, for example -- it would just
by-pass any auth request.

6. The PAM developer's manual indicates that modules should accept the
generic options 'debug' and 'use_first_pass', and potentially silently
ignore them.  I think pam_helpers.c will complain about the latter
option.
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/mwg-see-options.html

7. The pam_otpasswd module has a debug logging mode, which presumably
is aimed at you (the developer :-).  Would there be any reason to add
an "audit" option which is aimed at the sysadmin to provide a little
more day-to-day logging?  (As it happens, I appear to already have
documented this option :-)

8. When pam_otpasswd doesn't recognize an option, it returns a
PAM_AUTH_ERR.  I'm not sure that this is the best approach, since any
minor misconfiguration could lock-out any authentications using the
module.  I believe that the typical PAM behavior is to log the option
error, and then just continue processing.

9. It wasn't entirely clear to me (I'm just in the process of looking
over the module) -- are the suggested system logging levels being
observed, as per
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/mwg-see-programming-syslog.html
?

10. You return PAM_IGNORE when pam_sm_close_session() is called -- I'm
never sure if it should be PAM_IGNORE or PAM_SUCCESS.  What are your
thoughts on this?

11. In pam_helpers.c, I'm unclear what PAM return code is given when
the user is not known to OTPasswd.  Specifically, the code is roughly:

        /* We must know the user of whom we must find state data */
        retval = pam_get_user(pamh, &user, NULL);
        :
        /* Initialize state with given username */
        if (ppp_init(s, user) != 0) {
                /* This will fail if we're unable to locate home directory */
                goto error;
        }
        :
error:
        print_fini();
        return retval;
}

It almost looks to me as though whem pam_get_user() returns
PAM_SUCCESS, and ppp_init() fails, then the function returns
PAM_SUCCESS?  What am I missing?

12. I noticed that in the man page for pam_unix(8), they discuss
SIGCHLD handling.  Is this anything that pam_otpasswd should be
worried about?  It sounds like they ran into trouble with applications
receiving the SIGCHLD after the helper binary quit, and the signal
handler for the application that called PAM freaked out.

Alright.  That's it for now.  :-)

Hannes.