I’ve been seemingly wasting my time looking at OpenAFS code. Newer kernels have the sys_call_table in a read only code block which prevents OpenAFS from hooking the set_groups() syscall which prevents PAGs from working properly. The solution here is to migrate OpenAFS to use the kernel keyring system written by David Howells. There has been questions, but no movement or code in the OpenAFS community to make use of the kernel keyrings. So I thought I’d look at things myself.

OpenAFS deals with a cred_t struct that contains credential information. Which is in the form of a pointer to the current process’s group_info struct. The pointer is copied in on cred creation and the group_info struct is updated for the current process when the cred structure is “set.” Only the afs_setgroups() call gets the groups/creds changed for the process which is called by setpag(). However, anytime OpenAFS needs to know the current PAG is digs it out of the group_info struct. Which makes things not easy to migrate to a new system of storing the PAG.

What looks to be a decent idea is to create a couple functions. First, afs_get_groups_from_key() which would return a fake group_info struct populated with the PAG information from the key’s payload. Secondly, afs_set_group_in_key() which would save the current PAG information in the provided group_info struct into the current key’s payload. Yeah, the names are a little verbose. This would require changes in setpag(), crref(), and crset() as well as not hooking the sys_call_table and providing the key_type. (The crref() function creates a cred_t struct.)

This looks good as it doesn’t require API changes in AFS’s userland tools. The kernel manages the keys and no more syscall hooking! I haven’t quite figured out how the condition will be handled when a process requests a new PAG but that’s fairly minor. The big problem is that the kernel keys aren’t meant to be used this way. The kernel can search and read/write the payload data in the keys but it cannot manage them. Creating, managing, setting permissions is all supposed to be done by a userland process. Which makes the whole thing a lot more painful. Finally, this emailmakes sense.

Previous | Back | Next


comments powered by Disqus