From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Howells Subject: Re: [PATCH] in-core AFS multiplexor and PAG support Date: Tue, 13 May 2003 19:53:22 +0100 Sender: openafs-devel-admin@openafs.org Message-ID: <9828.1052852002@warthog.warthog> References: <20030513182950.GB30766@delft.aura.cs.cmu.edu> Mime-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Cc: David Howells , Linus Torvalds , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, openafs-devel@openafs.org Return-path: To: Jan Harkes In-Reply-To: <20030513182950.GB30766@delft.aura.cs.cmu.edu> Errors-To: openafs-devel-admin@openafs.org List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Id: linux-fsdevel.vger.kernel.org > On Tue, May 13, 2003 at 06:42:49PM +0100, David Howells wrote: > > I have a further suggestion for some new system calls specifically for > > managing tokens. I'd like to add the following: > > > > (1) settok(const char *fs, const char *key, size_t size, const void *data) > > > > Present data to the named filesystem as being the authentication > > token for the specified key (eg: an AFS cell). If accepted, this > > token should be stored in the PAG to which the calling process > > belongs. > > Tokens are very filesystem specific, with Coda the kernel really doesn't > know in which 'realm' any object is located. So it will always just pass > the PAG to the cache manager which will associate the right token to > access the file. OTOH, since settok wouldn't modify the PAG ring directly, but would rather jump through a vector in the file_system_type object, it could deside to confer with userspace and possibly not add a token at all. Of course then the other calls would also have to vector through the file_system_type object rather than affecting the PAG directly, but I'm happy to do that. > A minimal kernel implementation really only has a single newpag() > systemcall and internal 'getpag()' that can be used by filesystems. All > the token handling can be done by a (possibly filesystem specific) > userspace daemon that is given a (pag,realm/key) tuple and returns a > token. > > But ofcourse Coda is a 99% userspace implementation, so I'm already > assuming that there are one or more userspace daemons. This would just be a "standardised" way of communicating authentication info to a filesystem. What the filesystem then did with it would be up to that filesystem. Storing a token in a PAG or attached to a struct file would then just be one option. > > (2) gettok(const char *fs, const char *key, size_t size, void *buffer) > > > > Get a copy of an authentication token. > > Not sure what the use of this is for userspace. I can see how your > kernel module would use it. OpenAFS has it, but I'm not sure what uses it. > btw. is the 'size_t size' the size of the key, or the size of the buffer? Actually the buffer size. I was assuming the key would be a NUL terminated string, but it's probably best not to assume that, and I should add an extra argument for the key size. Filesystem name can remain a NUL terminated string as I'd have to search the file_system_type structures. > > (4) cleartoks(const char *fs) > > Isn't this simply deltok(fs, NULL)? Probably. David