Date: Thu, 24 Oct 1996 21:28:30 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> To: softweyr@xmission.com (Softweyr LLC) Cc: wollman@lcs.mit.edu, security@FreeBSD.ORG, softweyr@xmission.xmission.com Subject: Re: Any FreeBSD security topics of interest? Message-ID: <199610250428.VAA09284@GndRsh.aac.dev.com> In-Reply-To: <199610242310.RAA01706@xmission.xmission.com> from Softweyr LLC at "Oct 24, 96 05:10:35 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > I have to say that I have always preferred AFS's per-directory ACL > > semantics to the more commonly implemented per-file ACLs. AFS does > > not use the group and other permission bits at all, but applies the > > user bits as a mask against certain rights given by the ACL. The > > permission bits in AFS ACLs are `rwidlka', for `read', `write', > > `insert', `delete', `lookup', `lock', and `administer' (i.e., change > > the ACL). This enables certain nice features such as authenticated > > local mail delivery (make a directory with permissions `System:AnyUser > > lik' and they can create new mail files in that directory but cannot > > read, write, or delete existing ones; the owner of the file is the > > authenticated sender). > > I had the opposite reaction the first time I read about them: why did > they do this? The AFS ACL system does not, for instance, allow you to > make a setuid-root executable that can be run by wes, sam, and DJ, > but nobody else, unless you create a group that holds only those people > and make it group executable. This leads to a lot of small special- > purpose groups that have to be maintained. > > The per-file ACLs do demand more administration, but also allow more > power and flexibility. > > The AFS model does show that we can implement more semantics that just > read, write, and execute however. The overlaid semantics of rwx and > sticky on directories could be eliminated by adding a 'delete' privilege > to the file ACL, like VMS has. > > Lotsa design work to be done on this project, eh? ;^) Lotsa research should be done before _any_ design work. At a minimum I would look at 3 or 4 implementations that exist today, say for example the VMS you mentioned (has everything including the kitchen sink), Apollo (now HP) Domain/OS (but go to the real root of that design, Apollo Aegis, the first _real_ ``the network is the computer'' design), consider what AFS has implemented, and then someone like Primos or other unix ACL variant. Personally, I would do a mixed implemtation of Aegis ACLS, with the addition of file access alert classes and some of the other ``special'' VMS acls, and use the VMS Logic Name Table mechanism for ``variant'' ACL's (and added whistle by me :-)). I would retain the Aegis Initial default file and default directory ACL's. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610250428.VAA09284>