[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Permission models [was: Re: About the login shell]



Lionel Elie Mamane wrote:

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.
You're right, I stand corrected.

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?
You're right again, AFAIK. I'd also be interested in insight from whoever has it.

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.
Ah, but they were written that way to begin with. I'm sure that it is possible to port all UN*X programs to an ACL-based model, I'm just thinking about the work needed to do it, since there is already a lot of porting to do.

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.
Say there's a file on a GNU/Hurd box called /home/tom/foo.bar, whose standard UN*X permissions are wrxwrx---. Futhermore, say there's an ACE on it that explicitly grants user Lionel read permissions. Would an unmodified UN*X program see this ACE, and let you read my file? Or would such programs have to be patched to see beyond the standart UN*X permissions to the ACLs? (I'm assuming that most UN*X programs check the file permission bits set by the filesystem, which has to do with the implementation of ext{2,3}fs, ufs, etc., right?)

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.
Right. Such programs would use some sort of "standard UN*X" <--> ACL translation library, I believe. Hence all the big, hard changes are made in one place, and the programs just have to be re-written to use that library.

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.

I agree. This abstraction could come from the translation library mentioned above.

-- Tom Hart
hartte13@brandonu.ca



Reply to: