Re: [9fans] strange things in /sys/log/auth

["david presotto" <presotto@closedmind.org>]

Lots of possible problems.  If you change the bootes password, and convkeys
the file while still running keyfs with the old keys, you can easily hose
yourself.
You have to kill off the keyfs running with the old keys before you convkeys
anything.

----- Original Message -----
From: "andrey mirtchovski" <mirtchov@cpsc.ucalgary.ca>
To: <9fans@cse.psu.edu>
Sent: Wednesday, July 02, 2003 12:35 PM
Subject: Re: [9fans] strange things in /sys/log/auth


> i fixed the problem -- the /adm/keys file was fscked somehow.
>
> i was able to see directory entries for all users i've added in /mnt/keys,
> but after the directory listing there was garbage, the same thing Geoff
sent
> a few messages back. when started keyfs was reporting 'bad status in key'.
>
> i ended up doing:
>
> % rm /adm/keys
> % con -l /srv/fscons
> main: create /active/adm/keys bootes bootes 660
> % auth/changeuser bootes
> ...
>
> and then added all other users again. i've saved the old keys file, in
case
> anyone is interested in playing with it to see what's wrong. i've changed
> all passwords :)
>
> i'm a little worried, though -- i was thinking that bootes can only change
> passwords on the console, but killing keyfs and restarting it again as
> bootes in a local namespace gives me write privileges to /mnt/keys (though
> i loose the ability to login to the machine, naturally :)
>
> is it advisable to lock the keyfs process the same way factotum's process
> is? put it in the kernel? disallow 'echo kill > /proc/xx/ctl'?
>
> inquiring minds want to know :)
>
>
> On Tue, 1 Jul 2003, David Presotto wrote:
>
> > It means you have to:
> >
> > 1) kill keyfs
> > 2) run auth/convkeys on the keyfile
> > 3) reboot the auth server (or just give the new key to factotum on the
auth server)
> > 4) if you use an nvram on the auth server to store the key, use
auth/wrkey
> >   to rewrite it
>
>