Date: 15 Oct 1997 02:01:07 +0200 From: joda@pdc.kth.se (Johan Danielsson) To: Robert Watson <robert@cyrus.watson.org> Cc: Aleph One <aleph1@dfw.net>, freebsd-security@freebsd.org Subject: Re: C2 Trusted FreeBSD? Message-ID: <xofsou3nbcs.fsf@blubb.pdc.kth.se> In-Reply-To: Robert Watson's message of Tue, 14 Oct 1997 15:16:19 -0400 (EDT) References: <Pine.BSF.3.96.971014150845.1711A-100000@cyrus.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson <robert@cyrus.watson.org> writes: > > HP-UX has had ACLs for quite some time now but not one uses them > > just because of this. > > This is not entirely true; Right, I use ACLs on local file systems, when they are available. > ls is minorly-modified so as to ignore non-user permissions (AFS, as > I understand it, does maintain user rwx, etc, just not for others.) There are no changes to any user level programs in AFS. You need patched versions of cp/tar/pax/whatever if you want to preserve acls when copying files. In most situations this isn't a problem. The biggest problems are with `smart' programs that think they can figure out the permissions just by looking at the mode bits. The mode bits are preserved, but only the owner bits are used, and are used for everyone (xored with your acl-permissions). [per file or per directory ACLs] I actually find the per-directory acls in AFS a feature and not a bug. The only real problem is with ignorant users that just expects everything to work the same as in some other filesystem. The DFS approach to use ACLs on individual files is much more complex. > The by-directory ACL scheme does not work so well for /dev, for > example! File permissions doesn't work well in /dev at all. You really set permissions on objects, but a device file isn't an object, it's just a front-end to an object. It would be the same with files if you stored file permissions in the directories rather than in the inodes. /Johan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xofsou3nbcs.fsf>