From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Sun,  7 Apr 1996 14:32:14 -0400
From: Thomas Riemer triemer@babbitt.bernstein.com
Subject: Continuing on CPU/Auth
Topicbox-Message-UUID: 427a94c4-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19960407183214.vAviIR72T-iUdmSdaFq-xJilWczour9Bo74CSYxg34I@z>

Curiouser and Curiouser... 
The reason findkey in /sys/cmd/auth/lib/readwrite.c is failing is because
it can't find the file /mnt/keys/triemer/key.  
It is calling open on /mnt/keys/triemer/key - and failing to find
the file.

This is extremely odd since a standard ls on /mnt/keys/triemer/key says 
that it exists. This should be served by keyfs - if I'm correct.  

keyfs is started in /bin/cpurc - it prints out that it has read 3 keys
when it starts. 

Let me point out that as user bootes (the authid), I see 
/mnt/keys/triemer/key - however as user none, I do not.  It makes sense
that I should be able to see the keys as user none - I just don't know if
this is the way its "supposed" to be. 

As bootes, I can "cat" the file - it has 7 characters in it. 

Let me point out that I see the same behavior under the 9pccpudisk 
that came on the CD - as well as the 9pccpudisk that I built yesterday with
all the patches to /sys/src/9 (boot, pc, port) applied.

Of course, all of this logic is so simple to explain... I was running
/bin/auth/auth.srv as user none - not as user bootes, because I was
foolish enough to put il566 in /bin/services instead of 
/bin/service.auth/services.  Right about now, I feel like I have a few
bullet holes in my boots.   BTW - the authentication seems to work quite
nicely once I changed this.

-Tom
 


---- Where theory and reality meet. 
---- Thomas Riemer, tom@rockvax.rockefeller.edu