Date: Fri, 12 Mar 1999 10:36:41 -0500 From: Coranth Gryphon <gryphon@intech.net> To: Robert Watson <robert+freebsd@cyrus.watson.org> Cc: Wes Peters <wes@softweyr.com>, Matthew Dillon <dillon@apollo.backplane.com>, andrewr <andrewr@slack.net>, Archie Cobbs <archie@whistle.com>, Andrew McNaughton <andrew@squiz.co.nz>, freebsd-security@FreeBSD.ORG Subject: Re: disapointing security architecture Message-ID: <36E93489.495C0BF@intech.net> References: <Pine.BSF.3.96.990312094955.6494T-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> FS. Where did they find the space to store the ACLs? Adding any more
> serious data to the inode results in reduced performance as you chew
How much 'extra stuff' can we pack in before you hit that performance
degradation? Also, can anything be removed as obsolete to make more
room? Is there documentation (aside from existing code) on exactly what
is in the inode block now?
> forks (file:data, file:acl, NT-style) sounds interesting, but is a
> fairly large amount of work. I suppose one could use layering to do
> this--reserve the : character (or something else) and have a file
Gets messy when dealing with shared file systems.
> direct block pointers. Adding a new block that stores just ACL data
> sounds feasible, but removes the simplicity of the whole thing
This seems like the simplest approach, as most of the added work
is at least straight forward and not technically tricky.
My $.03
-coranth
---------------------------------------+----------------------------
Coranth Gryphon <gryphon@hway.net> | Work Phone: 561-912-2497
Chief Architect, Hiway Technologies | #include <std.disclaimer>
---------------------------------------+----------------------------
When all else fails, do the impossible.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36E93489.495C0BF>