The keyboard of Rainer Toebbicke emitted at some point in time:
>
> As Doug has already pointed out, all the schemes that basically know the
> users password or the srvtab-capable Kerberos hash thereof all suffer the
> problem of how to transmit that information safely, how to keep it in a safe
> place, and (more annoyingly) what to do when the user changes password.
Spring comes, and the issue of batch tokens raises it's head. The
problem is easy to solve in principle, once people analyse it
correctly.
The batch job needs resources (access to files). It has learned to
open the file before reading it - or rather, programmers have learned
to allow for that. They will have to learn to obtain a token, either
o before opening, and then closing the file quickly, or
o before any access, which would impair performance (probably,
although in most cases not much, IMHO), or
o sporadically, which means they have to monitor (real) time, or
o on error, which means an error condition and a handler.
The system has actually taken the second approach, checking every
access, so performance cannot be such an issue. On a system level, it
could also freeze the requesting job on expired access, instead of
killing it, and ask a suitably qualified object (the submitting user,
presumably) for a refreshed ticket.
The principle is no different from repairing a house, were the extend
of the work needed can economically only be established while the work
is going on, but people do not usually hand their buiders a blank
checque and tell them to get on with it (the equivalent of running
without expiring resource access authority).
> token - PGP is one way on how to address that. The advantage of such a scheme
> is that no passwords ever float around, and that on the 'secure server' side
> one has extensive logging and full control on what to grant to whom.
The problem is the concept of a "server". If its automated, the
security is gone. Just like processing time, research grants, or
whatever, batch jobs should be given a limited amount of resources. To
get more, they must show that they are doing useful work related to the
problem they were meant to address. Trying to bypass this complexity of
review and reschedule limits the batch jobs to "Micky Mouse" tasks.
Thomas
* email: cmaae47 @ imperial.ac.uk
