From owner-freebsd-arch@FreeBSD.ORG Mon Apr 23 12:22:19 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D630116A404; Mon, 23 Apr 2007 12:22:19 +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 AFA8813C4B0; Mon, 23 Apr 2007 12:22:19 +0000 (UTC) (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 29E9046B80; Mon, 23 Apr 2007 08:22:19 -0400 (EDT) Date: Mon, 23 Apr 2007 13:22:19 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Howard Su In-Reply-To: Message-ID: <20070423132006.T26224@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Pawel Jakub Dawidek Subject: Re: move audit/priviliage check into VFS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2007 12:22:19 -0000 On Sun, 22 Apr 2007, Howard Su wrote: > When I working on tmpfs privilege, I need copy a lot of privilege check code > from UFS. I suppose there is same problem in ZFS. So moving this sort of > privilege code into VFS will reduce a lot of duplicate code and also make fs > implementation simple and consistent in security thing. > > Besides that, some quota/extattr feature can be also implement in VFS layer. > > I suppose the fact today that a lot of stuffs are UFS related is because we > have VFS after UFS. So VFS only abstracts the common stuffs for a misc file > system like iso/udf/msdosfs. We didn't suppose we will have more > full-featured file system besides UFS. (NFS has its own & different > implementation about security.) > > Does VFS have other design goal that I am not aware to preventing us moving > more shared code into it? Pawel and I have talked about this a bit in the past -- vaccess(9) and vaccess_acl_posix1e(9) were really the first step in abstracting file system access control decisions, and aren't a bad step -- they certainly cover a lot of the previously plentifully replicated cases (countless foo_access() VOP implementations). However, I think we should be restrained and do a bit of experimentation -- sometimes as much work could be done bundling up the common arguments to deliver them to a central access check as is done in having the access check appear in the calling code itself. Can we refine VOP_ACCESS() a bit further to get what we need, or do we need new common functions? Robert N M Watson Computer Laboratory University of Cambridge