Re: [Plug] ACL for linux?

["Tracy Nelson" <tmnelson@acm.org>]

From: Vale_Kenny@vanguard.com <Vale_Kenny@vanguard.com>
Date: Thursday, July 29, 1999 14:50


>And I'd like to make a plea for role-based access control. Admittedly, it's
not
>going to be terribly useful in a Linux system due to the limited number
>of users, but it would be nice anyway.

How would role-based security be different from group-based security?

>I believe VMS has some nice features in this area

Actually VMS has pretty much the same security structure as Unix, with the
addition of "privileges" which can permit certain classes of action (e.g.,
with PHYSIO privilege, you can perform physical device access, ALTPRI
privilege permits you to alter your process priority).  For additional
security and file sharing VMS now has...ACLs! (Due to the fact that,
unlike Unix, users can only belong to one group.)

>The question of what to do with programs that don't understand the new
>protection scheme, however, is a thorny one. I'd suggest some kind of
>per-process setting indicating whether to not report any information (ie.
all
>files apparently end up with mode 0) or whether to report some kind of
>dynamic derived mode, which has the disadvantage that you'll end up with a
>many-to-one mapping of protection status to mode (eg. `foobar' is mode
>440 to you, but mode 460 to someone else, because you only have read access
>whereas they have write access too). The former has the
>disadvantage that you won't be able to use off-the-shelf applications, and
the
>latter might well cause all kinds of horrid (though rare) errors.

I wouldn't think either scheme would be too bad.  If you don't want to make
any
information available, then you get an error trying to stat(2) the file,
just like you
currently do if you don't have access to a file.  In the second case, there
shouldn't
be any errors with dynamic generation of access modes.  It's just like the
current situation with groups -- a file with mode 751 will have read and
execute
privs for anyone in the proper group, but execute-only priv for anyone not
in the
group.  And if you're implementing this at the file system level, you have
control
over the behavior of open/close/read/write/seek/stat, so you wouldn't even
have
to recompile statically-linked programs.

>Categories of protection may also be a problem. RACF gets around this by
having
>NONE, READ, MODIFY, ALTER, and this seems a reasonable
>solution. Another solution might be to specify groups of actions (read,
write,
>open with read only, lock etc.).



_______________________________________________
Plug maillist  -  Plug@lists.nothinbut.net
http://lists.nothinbut.net/mail/listinfo/plug