9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
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



      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).