From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 24 11:57:13 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 3D67E16A4E1 for ; Mon, 24 Jul 2006 11:57:13 +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 5C1EA43D70 for ; Mon, 24 Jul 2006 11:57:12 +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 4049E46CBD; Mon, 24 Jul 2006 07:57:11 -0400 (EDT) Date: Mon, 24 Jul 2006 12:57:11 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: delphij@delphij.net In-Reply-To: Message-ID: <20060724125154.T44945@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1014467017-1153742231=:44945" 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 11:57:13 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1014467017-1153742231=:44945 Content-Type: TEXT/PLAIN; charset=ISO-2022-JP; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 24 Jul 2006, Xin LI wrote: > On 7/24/06, =CD=FB=BE=B0=DB=BF wrote: >> The code for ipcperm() call : >> 78 ipcperm(td, perm, mode) >> 79 struct thread *td; >> 80 struct ipc_perm *perm; >> 81 int mode; >> 82 { >> 83 struct ucred *cred =3D td->td_ucred; >> 84 int error; >> 85 >> 86 if (cred->cr_uid !=3D perm->cuid && cred->cr_uid !=3D perm->= uid) { >> 87 /* >> 88 * For a non-create/owner, we require privilege to >> 89 * modify the object protections. Note: some other >> 90 * implementations permit IPC_M to be delegated to >> 91 * unprivileged non-creator/owner uids/gids. >> 92 */ >> 93 if (mode & IPC_M) { >> 94 error =3D suser(td); >> 95 if (error) >> 96 return (error); >> 97 } >> 98 /* >> 99 * Try to match against creator/owner group; if not,= =20 >> fall >> 100 * back on other. >> 101 */ >> 102 mode >>=3D 3; >> 103 if (!groupmember(perm->gid, cred) && >> 104 !groupmember(perm->cgid, cred)) >> 105 mode >>=3D 3; >> 106 } else { >> 107 /* >> 108 * Always permit the creator/owner to update the obj= ect >> 109 * protections regardless of whether the object mode >> 110 * permits it. >> 111 */ >> 112 if (mode & IPC_M) >> 113 return (0); >> 114 } >> 115 >> 116 if ((mode & perm->mode) !=3D mode) { >> 117 if (suser(td) !=3D 0) >> 118 return (EACCES); >> 119 } >> 120 return (0); >> 121 } >>=20 >> why not directly return the error in line 94? > > I think it makes sense to remove the assignment and the 'error' variable.= =20 > Let's see Robert's opinion. In almost all cases, we return the error returned by suser() in order to=20 encapsulate the notion that the "lack of privilege" error (EPERM) in suser(= )=20 rather than scattered around. I'm not sure it makes much difference, since= =20 functionally you will get back EPERM either way, but generally the conventi= on=20 has been for pieces of access control logic to return an error reflecting t= he=20 nature of the success or failure (0, EPERM, EACCES, ESRCH, etc), and for th= e=20 calling code not to perform any translation of the error unless strictly=20 necessary. For example, in procfs we do translate ESRCH into ENOENT, but o= nly=20 because ESRCH isn't a standard file system error, and ENOENT is the logical= =20 equivilent. In our TrustedBSD SEBSD branch, the MAC Framework permits=20 policies to modify the notion of privilege, so in principle they can return= =20 different errors from the privilege check, although I am not entirely sure= =20 they shold. I am not sure that I agree that we should replace the current= =20 error assignment, as it will encode EPERM as the privilege error in ipcperm= (),=20 and prevent suser() from returning a different error. Robert N M Watson Computer Laboratory University of Cambridge --0-1014467017-1153742231=:44945--