OK, I think I can say that I've figured out what I think the onauth API
should be, so I'd like to get some comments on it.  I haven't done any
implementation yet (other than copying John's onchange function and doing
the search & replace).  Assuming I get positive feedback, I'll move
forward with the implementation.

The onauth script will be given 4 parameters. the first three of which
will come from the parameters to the call_onauth function.

  $1 is the username. [1]
  $2 is the domain name or NULL if it's a system user. [1]
  $3 is the numeric value associated with the service type. [2]
  $4 is the current timestamp as generated by time(NULL). [3]

[1] The username and domain name are passed separately because they are
already broken apart in order for vchkpw/vpopmaild to authenticate the
user, and would have to be concatenated together before calling onauth,
and then split back apart by the onauth script.  That increases the
workload on both ends, so why bother.

[2] Except when being used to determine whether a particular service is
authorized in vchkpw, this information is never used.  I think it might be
good to pass a long for logging purposes, but see no reason not to stick
to numeric codes, and let the called script deal with the information as
it sees fit.  I'll add defines so that vpomaild and  other have numeric
code designations as well, and they remain static unless someone decides
to renumber them.

[3] While strictly not necessary (the script can calculate it on its own),
if you are using a script that just hands off the parameters to a daemon
which queue's up the updates, it's possible that any given onauth script
won't be processed until after the timestamp has changed.  Since we can't
guarantee that the onauth script will be run atomically, it's better to
send the timestamp as a parameter and let the script decide if it cares.

Other API notes:

The call to call_onauth should probably return the exit status of the
onauth script, which can be gotten after the wait(&pid) call returns.  And
instead of returning 0 for a failed call, return -1.  I'm not sure if we
care about that, but it's information that might be useful later on.

Other code notes:

There's a couple of minor issues I see in the onchange code, which I'll
fix in my onauth code and you can port back to the onchange code.  Mostly
the handling of a failed exec call - you should call _exit rather than
return, since it's in the vfork and you don't want the vfork'd process
doing anything more...

Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
  - Layman's translation of the Laws of Thermodynamics

Reply via email to