Continuing on CPU/Auth

Continuing on CPU/Auth

[Thomas]

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