> That was not my understanding.  I guess we first need to decide which
> problem(s) we are trying to solve.  (i.e. What are the requirements?)
> 
> I thought we were trying to `provide a flexible way to do things like
> change the ownership of "related devices" at login/logout time.'
> 
> It sounds like others want a different problem solved, that of
> `allowing additional authorization checks at login time.'
> 
> The two problems seems quite separate to me.  The first one does
> things that depend on what tty is involved but NOT what user is
> logging in (the same action will happen for any user).
> 
> The second (authorization) problem typically depends on site
> policy, where inputs to that policy may include a long list
> of things as you have suggested.

I agree that the problems should be solved seperately, but it's not
clear that they require 'inputs' that are that much different.

For instance, i could very easily want to say:

Give whoever's logging in on console access to the console tape drive,
except for JoeBob, because he always puts in TapeDriveMangler(TM)
tapes.

_both_ depend on site policy, in regard to how resources and users are
managed.


However, as i said before, I don't think they should be solved
together, because, while they do overlap a little bit, solving them
with one solution causes both implementation and administration
difficulties.

It's also worth noting that it may be possible to do something like
implement a "logincheck" action in the future.  As long as the return
value from ttyaction() has some meaningful value (i'd say: the exit
code of the child would be a reasonable one), it could be used.
However, I _really_ don't think that checking whether or not to allow
a login at all should be glommed on to the 'login' action.


cgd