From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <000901c34192$d0dc1220$1728ff87@bl.belllabs.com> From: "david presotto" To: <9fans@cse.psu.edu> References: Subject: Re: [9fans] strange things in /sys/log/auth MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Date: Thu, 3 Jul 2003 14:42:10 -0400 Topicbox-Message-UUID: e6e9978c-eacb-11e9-9e20-41e7f4b1d025 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" 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 > >