From: presotto@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] possible way to have the secstore on the cpu server
Date: Mon, 17 Jun 2002 07:51:16 -0400 [thread overview]
Message-ID: <b824b50e8f53c4d11362f79ca96e9111@plan9.bell-labs.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 143 bytes --]
Thanks, I understand now. I think its time to add a ctl to factotum.
It already has all the code the read secstore so its easy enough
to do.
[-- Attachment #2: Type: message/rfc822, Size: 5800 bytes --]
[-- Attachment #2.1.1: Type: text/plain, Size: 917 bytes --]
At the point factotum starts on the cpu server, there is no secstore
service running, because cpurc has not yet run to start it.
Thus, in cpurc, after I have started the secstore service, I want to do
auth/secstore -G factotum | read -m >/mnt/factotum/ctl
to load the secstore into the already running factotum. This will prompt
for the secstore password, which is a pain if I want to reboot the cpu
server remote.
So, I grafted the nvram key loading code from factotum into secstore
under the option -N. The relevant bit of cpurc is:
dossrv
@{
rfork n
mount -c /srv/dos /n/9fat /dev/sdC0/9fat
bind /n/9fat/secstore /adm/secstore
auth/secstored
echo secstored running
auth/secstore -N -G factotum | read -m >/mnt/factotum/ctl
echo keys loaded
}
Now if there is a clever way to get factotum to reload itself from
secstore I would use that, but I don't think there is.
[-- Attachment #2.1.2: Type: message/rfc822, Size: 3353 bytes --]
[-- Attachment #2.1.2.1.1: Type: text/plain, Size: 142 bytes --]
Also, I'm confused. Factotum already did read the nvram key, we
rely on it here for exactly what you use if for. What did you have
to add?
[-- Attachment #2.1.2.1.2: Type: message/rfc822, Size: 1666 bytes --]
From: nigel@9fs.org
To: 9fans@cse.psu.edu
Subject: Re: [9fans] possible way to have the secstore on the cpu server
Date: Sat, 15 Jun 2002 15:02:51 +0100
Message-ID: <0538a1a8b42ab0f0bb459fc5e0ed97a9@9fs.org>
Good points all. Presotto had said a dictionary attack was possible if
the service ran on the cpu server and I can't see it.
Anyhow I've implemented it all, and perhaps will drop it all in the wiki
at some point.
One addition is a mod to secstore so it reads the nvram key rather than
prompting for one. This allows cpurc to load the cpu servers's factotum
with extra keys like the SSL ones.
Secstore is cool; it takes my mind off the awful VGA support.
next reply other threads:[~2002-06-17 11:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-17 11:51 presotto [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-06-17 10:25 nigel
2002-06-15 15:34 presotto
2002-06-15 15:32 presotto
2002-06-15 14:02 nigel
2002-06-14 16:42 Russ Cox
2002-06-14 8:26 nigel
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=b824b50e8f53c4d11362f79ca96e9111@plan9.bell-labs.com \
--to=presotto@plan9.bell-labs.com \
--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).