From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3994b5823f7464b123e94245e6526592@proxima.alt.za> To: 9fans@cse.psu.edu Subject: Re: [9fans] factotum/802.1x catch 22? Date: Sun, 25 Mar 2007 16:46:21 +0200 From: lucio@proxima.alt.za In-Reply-To: <200703251156.l2PBujR12676@zamenhof.cs.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 30cef53a-ead2-11e9-9d60-3106f5b1d025 > 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 /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