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:21:05 +0100 Sender: openafs-devel-admin@openafs.org Message-ID: <9558.1052850065@warthog.warthog> References: <20030513172029.GB25295@delft.aura.cs.cmu.edu> Mime-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Return-path: To: Jan Harkes , Linus Torvalds , David Howells , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, openafs-devel@openafs.org In-Reply-To: <20030513172029.GB25295@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 > Right, if some process/user opens a file and then passes the descriptor > to another process/user which closes it. The close should operate under > the same permissions as the original opener. As long as the token isn't explicitly withdrawn. With my token structure, I've defined it such that if the list_head in the token struct is ever empty, then the token is withdrawn. Furthermore, I'm considering it such that the the filesystem will select a token from the PAG's token ring in the file_operations->open method and will attach it to the file->f_token at that point for quick reference later. > If someone obtains my user id on in any way (i.e. weak password/ > bufferoverflow/ root exploit), he should not be allowed to use or access > my tokens as he hasn't proven his identity. In this case he would either > still be in his original process authentication group, or a new and > empty PAG. But definitely not in any of my authentication groups. > > Which is also why joining a PAG should never be allowed. Someone asked for it, but I suspect if allowed at all it may be best that this ability is governed by its own capability bit and also that the security interface should be consulted. David