> 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