From owner-freebsd-arch@FreeBSD.ORG Mon Apr 23 12:13:23 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 C8BD316A40A for ; Mon, 23 Apr 2007 12:13:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by mx1.freebsd.org (Postfix) with ESMTP id 60EE813C45E for ; Mon, 23 Apr 2007 12:13:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.227] (helo=fw.zoral.com.ua) by relay01.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1Hfx4F-000NV5-Bm; Mon, 23 Apr 2007 14:50:52 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id l3NBojH8027264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 14:50:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l3NBojTv022869; Mon, 23 Apr 2007 14:50:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l3NBogef022868; Mon, 23 Apr 2007 14:50:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 23 Apr 2007 14:50:42 +0300 From: Kostik Belousov To: Howard Su Message-ID: <20070423115042.GF2052@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZRyEpB+iJ+qUx0kp" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-0.1 required=5.0 tests=ALL_TRUSTED,SPF_NEUTRAL autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on fw.zoral.com.ua X-Scanner-Signature: a96565856d7d777f03ae631b61e05b17 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 972 [Apr 23 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release 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:13:23 -0000 --ZRyEpB+iJ+qUx0kp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 22, 2007 at 02:58:30PM -0700, 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. >=20 > Besides that, some quota/extattr feature can be also implement in VFS lay= er. Quota code (ufs/ufs/ufs_quota.c) is mostly filesystem-independent, it only require particular format for the quota file, and several fields in the ufs mount structure, as well as ufs mount interlock. The later could be factored-out quite easily. On the other hand, only ufs is stuffed with hooks for the quota handling. > 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.) >=20 > Does VFS have other design goal that I am not aware to preventing us > moving more shared code into it? I would let others comment on the feasibility of factoring out permission check code. What I want to point out is that some time ago UFS itself was considered as layer with underlying implementation providing the actual structure for the storage. At least two such implementations existed, FFS and LFS. The LFS is long dead and removed from CVS. All that left from the layering is several method pointers in struct ufsmount. I suspect that current code has eroded the border between UFS and FFS. That said, I'm not sure whether implementing tmpfs as some TMPFS under UFS layer is possible now, but you may look at this. --ZRyEpB+iJ+qUx0kp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGLJ2SC3+MBN1Mb4gRAqU9AJ92Mk4kvJjEjqOAjaOecvzsNADOIwCfX+8z SHEMG/asdtfqje0f/7fuhAs= =6TKx -----END PGP SIGNATURE----- --ZRyEpB+iJ+qUx0kp--