> what you say seems to imply 'copying' (functionality of)
> secstore(1) flags, like '-s server'.
> but then, where to stop?
Perhaps. As I see it, there are conventions in factotum designed to
handle the case where keys are needed from the secstore. I can only
presume that the default secstore in this case is found in the same
place as the auth server, as described for the -a option:
-a supplies the address of the authentication server to
use. Without this option, it will attempt to find an
authentication server by querying the connection
server, the file <mtpt>/ndb, and finally the network
database in /lib/ndb.
Either that, or there is an analogous approach for the secstore that I
am not familiar with (it isn't obvious from the description of the -S
option in the man page, perhaps it ought to be).
If you allow a command to trigger the operation of the -S option, then
in any case the conventions will apply, but it seems to me that they
may need qualification. In fact, they probably already do, but
convention rules. Certainly, factotum as built into the kernel does
not use secstore to retrieve the keys a CPU server may need, so adding
a minute and optional amount of selectivity isn't likely to hurt as
much as adding rc to the kernel image.
And that of course raises the question of what to do if the only form
of networking available is 802.1x and the secstore is remote. But I
must qualify what may be a stupid question with the disclaimer that I
know nothing about 802.1x and I may well be making a fool of myself
here.
++L
