On Tue, Aug 20, 2002 at 11:28:07AM -0500, Tom Hart wrote: > Lionel Elie Mamane wrote: >>On Tue, Aug 20, 2002 at 05:28:12PM +0200, Robert Millan wrote: >>> Well i think we can reach something much more secure than the "all >>> or nothing" unix traditional approach, too. >>> Let's say i want to set a public console for html browsing; on the >>> GNU system the browser could be set as the only application the >>> guest user can execute. >>> But to get it really flexible this would need a large permission >>> table, though, where each file has a permission set for owner, >>> each user and each group. I don't know if this is scalable. >> Isn't that (functionally) the idea behind ACL's, while they tend to >> be implemented as just that: lists, and not a big table? > ACL's (Access Control Lists, for those who haven't heard the term > before), are, theoretically, a superior form of security for an OS, > since they allow the administrator to have more fine-grained control > over access to the system. Not only the administrator: The user, too, on his files. At school, when I'm working on a project with N other students, I appreciate that the system permits me to ask that only these N other students (and I) are permitted to modify the files. > I assume that the Hurd is sticking with the traditional UN*X model > because most sysadmins who are used to UNIX will find this easier to > work with. Hmm... The Hurd clearly departs from the UNIX way where it can do better, in a way that permits it to show an unixy interface to unix programs. I don't think this is the reason. Maybe someone that was around back then when those decisions were made can give some insight? > Furthermore, switching to an ACL-based model would probably break > compatibility with traditional Unices, or at the very least, require > a lot of work porting existing programs that depend on the UN*X > security model. Some systems / programs, like Samba and Solaris, already have to map an ACL model into the Unix model, and vice-versa. As far as I know, they don't fare that bad in doing it. More importantly, I don't see many programs that rely on the Unix security model. What interactions does a typical program have with the security model: The user requests some action (e.g. open a file). It fails, because it is not authorised. Report it to the user. What does an ACL-based system change there? The program doesn't care why exactly the action is not authorised. Programs like su, sudo, et al: They don't care either: They just want to change permissions to the ones of another user. They do various setuid-family calls, no direct interaction with the security model, except that it is multi-user (it has a notion of different users). apache serves a page only if the r bit of the o set is set. Given a decent mapping from the ACL system to the unix system, this still works: The ACL system surely has a notion of "permissions to any (authenticated) user". The programs that actually manipulate the permissions: chmod, etc. They have to be rewritten, or new tools written. Worse, this class includes file managers, who have to be adapted. Programs that used to *show* permissions, like ls. As the space to show the permissions given in an ACL system is not bounded (at least not by a reasonable bound), I don't think ls should show the whole ACL, only an "abstract" of it. And the mapping into Unix permission bits is a good candidate. Obviously, you need *another* program that shows the whole ACL. -- Lionel
Attachment:
pgpzhiPDhtt9T.pgp
Description: PGP signature