lkml.org 
[lkml]   [1999]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: linux capabilities and ACLs
On Thu, 4 Feb 1999, Albert D. Cahalan wrote:
> Good. POSIX ACLs are awful. Somebody stop the ext2 developers before
> it is too late. With a tiny bit of thought, it should be obvious
> that the inheritance system is broken. ACL systems that are much better
> include those of NT, Netware, Digital Unix...

I think the TOPS-10 system was conceptually much better, although the
implementation suffered from problems (mainly because it was a gross
hack). The basic idea is that the ACLs are *not* stored as some sort
of extended attribute of the files, like they are on most other systems.
Instead, the ACLs for a user's files are in a single file (I don't recall
if TOPS-10 actually did one file per user, or one per directory per user).

Basically, this file contains a list of descriptions of allowed and
non-allowed accesses, with wildcarding allowed. You could base things
on the name of the file (including path), the user and group of the
person trying the access, the type of accesses they were requesting,
and what program was trying the access.

The system only checked the access file if the access was not otherwise
allowed.

This doesn't conveniently do everything convention "ACL's as extended
attributes" do, but if you are reasonably organized in how you store
your files (e.g., you tend to put things with the same desired access
rules in the same directory), it works great.

There are two big advantages compared to the "ACL's as extended
attributes" approach.

1. No modification is needed to the format of any filesystem to
support this.

2. No modification is needed to existing utilities.

On TOPS-10, the access file was just a text file, and the wildcarding
was the same kind used for filename matching. I think on a Linux
implementation, I'd prefer full regular expressions, and probably
for speed have the text file compiled into a binary file.

I think this kind of system should be considered for Linux. I can see
some problems with hard links, but it might be a nice way to provide
most of the benefits of ACLs with almost none of the disadvantages
of the usual approach. If a Linux implementation kept the TOPS-10
behaviour of only checking the access file on accesses that would
otherwise fail, then there should be minimal backward compatibility
issues (the only thing that comes to mind offhand would be programs
that try to figure out on their own if something is allowed, rather
than just trying and letting the kernel tell them).

--Tim Smith

ps: the big problem with the TOPS-10 implementation was that the access
check was done by a daemon outside the kernel. When an access failed,
the kernel send a message to FILDAE describing the request, and FILDAE
told the kernel if it was to be allowed. People manage to find and
exploit bugs in the communication between FILDAE and the kernel to get
them out of sync.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.793 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site