[OpenAFS] fs setcrypt forcing

[Ted Anderson]

On 6/16/2003 17:32, Derrick J Brashear wrote:
> On Sat, 14 Jun 2003, Ryan Underwood wrote:
>>>>Hmm, what about connections to particular volumes, in that case?
>>>
>>>Came up in the usenix AFS workshop. Store the attribute where?
>>
>>Good question.  Perhaps in the vldb?
> 
> That's the logical place. You'd need a spare bit assuming there are any,
> and a way to reasonably set it. If there aren't any, new RPCs and a new
> version of the database incompatible but upgradable from the old

Putting this bit in the VLDB would seem straightforward, but then the 
file server would have to contact the VLDB periodically to get this 
information for each volume it serves.  This would add a new 
communication path to the system, I think, as the file server doesn't 
talk to the VLDB at all.  Or has that changed?

A more logical approach would be to look at the ACL and require crypt 
level connections if it doesn't include read access for system:anyuser. 
  The server can easily query the connection for the rxkad state after 
checking the ACL and refuse to leak information through this channel.

The question with this approach is whether there is a smooth way for the 
server to tell the client to use an encrypted connection if the ACL 
requires it and the client is using an unencrypted one.  Otherwise, the 
client has to use an encrypted connection all the time, or use some 
error code dependent retry loop.  Maybe the server's inclination to 
behave this way could be encoded in some server configuration bit.  Can 
this be reported to the client using a spare bit during connection 
setup?  If the client can find this out, it could use an encypted 
connection for lookups by default and safely determine the file's 
permissions.  When a file's access does allow read for system:anyother, 
it can switch to using an unencrypted connection when fetching or 
storing for improved performance.

Ted Anderson