From owner-freebsd-fs Wed Sep 27 5:58:57 2000 Delivered-To: freebsd-fs@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0DAAF37B423 for ; Wed, 27 Sep 2000 05:58:54 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id IAA89056; Wed, 27 Sep 2000 08:58:37 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 27 Sep 2000 08:58:37 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Boris Popov Cc: freebsd-fs@FreeBSD.org, trustedbsd-discuss@TrustedBSD.org Subject: Re: VOP_ACCESS() and new VADMIN/VATTRIB? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 27 Sep 2000, Boris Popov wrote: > On Tue, 26 Sep 2000, Robert Watson wrote: > > > I'd like to propose that an existing VADMIN flag be added determining > > whether or not the passed credentials are permitted to administer the > > file. Here is a brief itemization of locations in the code where i->uid > > checks would be replaced with VOP_ACCESS(vp, ... VADMIN ...) calls, with > > some possible omissions: > > Interesting, but will there a strict policy which declares > priority of this flag and its relation with suser() ? The semantics will not change: VADMIN may be exercised on a file either by virtue of being the owner of the file (in the case of UFS-like file systems invoking vaccess()), or by virtue of possessing appropriate privilege. In the base FreeBSD tree, appropriate privilege will be a successful invocation of the suser() call. In my capabilities tree, it will generally correspond to CAP_FOWNER, or the capability to override access control failure based on not owning the file system object. Although I haven't finished the integration of the changes yet, I believe the patch for kern/vfs_subr.c would look something like the following: --- vfs_subr.c 2000/09/21 15:55:55 1.277 +++ vfs_subr.c 2000/09/27 12:55:36 @@ -2976,6 +2976,7 @@ /* Check the owner. */ if (cred->cr_uid == file_uid) { + dac_granted |= VADMIN; if (file_mode & S_IXUSR) dac_granted |= VEXEC; if (file_mode & S_IRUSR) That is, if you are the owner of the file by the traditional owner definition, then the VADMIN right is added to the mask of rights granted via the discretionary access control mechanism. When the check occurs and fails, it is followed by a check for appropriate privilege. You could think of this as the "loose end" category for access control checks, but actually all of the rights associated with VADMIN fit quite nicely into the category "access granted based on owning the file", or the shorter "administrative rights for the file" (VADMIN). I would be willing to consider arguments for giving VADMIN a different name, possibly VOWNER, VSETATTR, etc. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message