Date: Mon, 24 Jul 2006 12:57:11 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: delphij@delphij.net Cc: freebsd-hackers@freebsd.org, =?ISO-2022-JP?B?GyRCTXs+MFs/GyhC?= <shangjie.li@gmail.com> Subject: Re: A question about ipcperm() call? Message-ID: <20060724125154.T44945@fledge.watson.org> In-Reply-To: <a78074950607232221q7c3f3028xbb22d85dfd677c49@mail.gmail.com> References: <de71d27b0607231907o6a7567bdy81e1a6d613b88c82@mail.gmail.com> <a78074950607232221q7c3f3028xbb22d85dfd677c49@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <shangjie.li@gmail.com> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060724125154.T44945>