From: lucio@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 [thread overview]
Message-ID: <3994b5823f7464b123e94245e6526592@proxima.alt.za> (raw)
In-Reply-To: <200703251156.l2PBujR12676@zamenhof.cs.utwente.nl>
> 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
prev parent reply other threads:[~2007-03-25 14:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-19 13:47 Axel Belinfante
2007-03-20 13:44 ` erik quanstrom
2007-03-21 23:03 ` Axel Belinfante
2007-03-22 4:38 ` lucio
2007-03-22 5:19 ` Uriel
2007-03-22 6:13 ` Noah Evans
2007-03-22 9:11 ` erik quanstrom
2007-03-22 15:31 ` Joel C. Salomon
2007-03-25 11:56 ` Axel Belinfante
2007-03-25 12:12 ` Uriel
2007-03-25 14:48 ` lucio
2007-03-25 20:38 ` Charles Forsyth
2007-03-26 6:51 ` lucio
2007-03-27 9:24 ` Charles Forsyth
2007-03-27 17:29 ` lucio
2007-03-25 15:40 ` erik quanstrom
2007-03-25 16:44 ` lucio
2007-03-25 20:15 ` Axel Belinfante
2007-03-25 14:46 ` lucio [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3994b5823f7464b123e94245e6526592@proxima.alt.za \
--to=lucio@proxima.alt.za \
--cc=9fans@cse.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).