In article <199604192059.NAA28691@stilton.cisco.com>,
David Carrel  <carrel@cisco.com> wrote:
> or may not have performed certain actions.  If it returns non zero, the
> authorization fails and the login terminates.  Since the default will be to

This isn't sufficient to solve the authorization problem.

> The payoff comes to those who use NetBSD for commercial services.  Those
> are the folks that need to control access times or access services.  Most
> folks like us have no need for this since we have personal machines, but
> that hardly means there's little need for it.

Nobody disagrees that it's not desirable; I've been thinking about how
to do this since some time after the S/Key stuff went in (at least a
year ago). What we disagree on is the assertion that "if and how should
the user be allowed to log in" is the same as "what should be done when
the user logs in"

> and highly general.  So let's not have two sets of hooks for a single
> problem.  Authorization IS the task of granting privileges.  Changing modes

But it isn't a single problem. There are two very distict problems here:

 - Is the user allowed to log in? If yes, what methods of validating the
   user are to be availible to the user (you may want to require OTP in
   some cases, for example, but not in all).

 - Once we've decided to let the user log in, are there any additional
   actions that root needs to take to set up the user's operating
   environment, such as giving access to devices.

There are very clearly two separate issues. We are only attempting to
solve the latter right now, in order to avoid confusion. I, for one,
plan to work on the former as well, but I want to get the latter out of
the way first, since it's a simpler issue.