Why I don't like ACLs and extended attributes

15 December 2004, 10:28 UTC

I really don't lile ACL's and extended attributes in filesystems. NFSv4 supports them and it makes it ugly. More and more filesystems are supporting them and it is just added complexity that really is the wrong way to go.

But me just saying that doesn't prove anything. So I should try to convince you, dear reader.

Unix has this elegant idea that "everything is a file" and futher that "a file is just a stream of bytes".

The trouble is that files are more than just a stream of bytes. They are also an owner, a group-owner, and a bunch of access control bits. Note that the 'name' is not part of the file, it is content of a directory. This is something that Unix definately got right.

Now it turns out that just an owner, a group, and 12 access control bits aren't enough to do the sort of access control that people want. So people started adding more and called them ACLs - Access Control Lists, made of Access Control Entries (ACEs). This was a mistake.

The better approach would have been to realise that adding ad-hoc attributes to a stream-of-bytes was the wrong way to go, and an approach that allowed the current attributes to be discarded would be better.

But how can we discard "owner" you might ask. And how would we do any sort of access control?

For the second part, I think apache is a good place to look. Apache allows very sophisticated access control on all files without having per-file attributes at all. There is a .htaccess file which describes the access allowed for the directory and it's contents. The power of this file is completely under the control of the server. Clients don't need to know details at all. This is good.

This approach makes it more awkward - though not at all imposible - to have different access policies for different files within a directory, so there is a tendancy to group files with similar access policies into similar directories. I think this is a good thing as it encourages people to think about where they put files.

If we were to provide a filesystem which used a protocol like http to access file from a server like apache, that would provide a simple way for people to share files with others to exactly the extent that they want. It would't provide exact Unix semantics, but it would be very usable.

So what about the first question: How could we cope without file owners.

A useful observation here is that it isn't files that have owners so much as directory trees. Each user has their home directory which should be entirely owned by them. There is no real need for individual file ownership. If the login process were modified so that when a user logs in their home directory is mounted at /home and no body elses homedirectory is visible, they you have all the protection that you need.

The shared-access server could be mounted at /share (for example) and anyone's files that have been declared to be accessable by the logged in user, could be seen.

Access through a server like this is likely to have some performance problems. For read-only access, caching would probably be enough to make it quite workable. However for group work for files that need to be completely shared, there might be problems.

To address this, we review the 'group' concept that unix currently has, and suggest that each group might have a home directory, and that those home directories should be mounted appropriately when the user logs in.




[æ]