From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 24 12:04:47 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E151516A4E0 for ; Mon, 24 Jul 2006 12:04:47 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA35B43D6D for ; Mon, 24 Jul 2006 12:04:45 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 67D4446CD8; Mon, 24 Jul 2006 08:04:45 -0400 (EDT) Date: Mon, 24 Jul 2006 13:04:45 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: delphij@delphij.net In-Reply-To: Message-ID: <20060724125831.S44945@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, =?ISO-2022-JP?B?GyRCTXs+MFs/GyhC?= Subject: Re: A question about ipcperm() call? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 12:04:48 -0000 On Mon, 24 Jul 2006, Xin LI wrote: >> why not directly return the error in line 94? > > I think it makes sense to remove the assignment and the 'error' variable. > Let's see Robert's opinion. I'm sorry, my previous answer was based on a mis-reading of the question -- you're not suggesting returning EPERM directly, rather, avoiding the "fall out" to the return (0). ipcperm() is not very well structured, in part because the access control logic itself isn't very well structured. Normally I try to structure access control functions so that we check all the possible reasons not to grant a request, and return (0) only if they all pass, returning various errors along the way. This works well in many cases because we often have lots of reasons not to allow something, and few reasons to allow it. For example, the p_checkfoo() inter-process access control checks. However, when discretionary access control is present, things get a little more complex, since the first task is to identify which set of rules are required, then to compose the mandatory rules, matching discretionary rules, and privilege. This is true in vaccess() and vaccess_acl_posix1e(), and should be true in ipcperm() also. I would be interested in seeing reasonable restructurings of this code, perhaps as a set of blocks that looks at each requested operation or set of related operations and authorizes them sequentially. Robert N M Watson Computer Laboratory University of Cambridge