From owner-freebsd-security Sun Mar 14 5:50:44 1999 Delivered-To: freebsd-security@freebsd.org Received: from obie.softweyr.com (unknown [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 0AF6314BFF for ; Sun, 14 Mar 1999 05:50:38 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.com (wes@zaphod.softweyr.com [204.68.178.35]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id GAA09329; Sun, 14 Mar 1999 06:50:12 -0700 (MST) (envelope-from wes@softweyr.com) Message-ID: <36EBBE93.DEC82C92@softweyr.com> Date: Sun, 14 Mar 1999 06:50:11 -0700 From: Wes Peters Organization: Softweyr llc X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Peter Jeremy Cc: freebsd-security@FreeBSD.ORG Subject: Re: disapointing security architecture References: <99Mar14.193150est.40323@border.alcanet.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Peter Jeremy wrote: > > Wes Peters wrote: > >My suggestion for FreeBSD would be to steal half of the disk direct > >blocks in the disk inode for ACL information. > > The downside of this is that _all_ files between 7 and 12 blocks long > (typically 48-96KB) will then need an indirect block - adding an extra > block to its size (additional indirect blocks are needed for other > sizes as well, but this first one is the biggest relative space/time > hit). Whilst this may be reasonable for a system where the majority > of the files have individual ACLs, I suspect this wouldn't be true > of most systems. Actually, only the ones that have ACLs will take this hit, since you don't have to reserve the space if the file type isn't "file with ACL." I see a couple of holes in this theory, though: you need ACLs on device files too, and it becomes very expensive to add an ACL to a file after the fact, since you have to "push down" all the blocks in order to clear the ACL entries. > IMHO, stealing an extra inode (or disk block) only for files that need > ACLs would be preferable (especially if ACL sharing is implemented). I agree, but I'm not sure how you would express the ACL sharing idea to the user. When the user adds an ACL to a file, are you just going to exhaustively search all existing ACLs to see if one matches? What do you do if two files are sharing an ACL and a user edits one? Change both? Split a new ACL? > Admittedly, we still need to find space for the additional pointer > in the inode. The ufs dinode has two "spare" int32_t's at the end, that should do it. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message