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 17:05:57 +0100 Sender: openafs-devel-admin@openafs.org Message-ID: <8812.1052841957@warthog.warthog> References: Mime-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Cc: David Howells , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, openafs-devel@openafs.org Return-path: To: Linus Torvalds In-Reply-To: Errors-To: openafs-devel-admin@openafs.org List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Id: linux-fsdevel.vger.kernel.org Linus Torvalds wrote: > On Tue, 13 May 2003, David Howells wrote: > > > > (1) PAG (Process Authentication Group) support. A PAG is ID'd by a unique > > number, and is represented in memory as a structure that has a ring of > > associated authentication tokens. > > > > Each process can either be part of a PAG, or it can PAG-less - in > > which case it has no authentication tokens. > > > > Two new syscalls are added: setpag and getpag. > > I think the code looks pretty horrible, Any particular bits? > but I think we'll need something like this to keep track of keys. However, > I'm not sure we should make this a new structure - I think we should make > the current "tsk->user" thing _be_ the "PAG". Maybe... There are arguments either way, but if the token ring is kept in struct user, a task can't detach from it and pass a token-less set of keys onto another process it wants to run. Also, using a separate PAG structure means that you can lend your keys to an SUID program and conversely it means a SUID program can't so easily gain access to keys it didn't inherit from its caller. I'm not sure that the ability to arbitrarily join a PAG should be permitted, but it was requested. David