Zope permissions and ACLs

A lot of Zope's shortcomings are a direct result of the Zope developers' decision not to trust coders.

I suppose their reasoning went something like this:

Imagine an academic environment where the school provides a web-server and the students created accounts on it where they could experiment, create dynamic web pages, and learn how to program. Kids are kids and are apt to look for trouble. The server should protect the good kids from the bad kids by making sure that one student's programs cannot access/modify/delete another student's data without their permission.

The same reasoning could be applied to a Plone sort of system on the web. Plone is a Zope product that is essentially a wiki for programmers. Any programmer can create a Plone account and upload code to the server, so there has to be some control to keep malicious users from abusing their accounts.

At a glance, this seems like very logical reasoning. I know that I don't want my data to be accessed, modified, or deleted by another user! However, there a couple big flies in the ointment…

First off, the system isn't terribly well documented. If you want to grant user A access to user B's data, then you may be in for a very rocky ride. There's a million different permissions and it's a total nightmare to guess which ones affect what. The documentation describing the process is painted with only very broad strokes, leaving the system administrator to experiment at length. In my experience, chances are that the sysadmin will either fail, or succeed by opening up more privileges than he had ever intended. Neither of these possibilities are appealing.

Secondly, the permission system is only safely changed by a system administrator. The sysadmin can allow user A to access user B's data, but user B can't grant that access to user A directly. This sort of design is inherently problematic because your typical sysadmin doesn't have time micro-manage such things.

Third, the permission system doesn't seem to work very well. I remember experiencing a recurring problem where user A could access files just fine if she had created them, but could not access the files created by user B, even after user A had taken ownership of these files. Zope assured us that user A owned the file, but yet, user A could not access the file.

Fourth, when the permission system keeps the users from doing something, it is never very clear why they were not stopped. Which of the rules were they trying to break? This fuzziness made it almost impossible to correct access problems when encountered.

And finally, this appears to be a solution in search of a problem. Your typical web development environment is not a school or a Plone type of arrangement at all. Your typical web development environment is a web server owned by a company and full of code created by the company's employees. There is no need to protect user A's data from user B because they are all on the same team. They are not anonymous users known only by their IP address.

I really think that PHP tackled this problem the right way by not tackling it at all. If you can upload a PHP script to a webserver and run it, then you can run code on that server. The server doesn't get in your way and try to keep you from doing dangerous things while allowing you to do a subset of activities that seem "safe". The PHP philosophy seems to be: If you don't trust a user, then you shouldn't let them upload code in the first place.

Access control should not be added in at a high level like the web server itself. We should rely on a system's lowest level ACL system. Linux (for example) has had far more rigorous testing done on it than Zope could ever dream of. I would much rather see a Zope replacement that suEXEC's as a user. Let's let the operating system protect user A's data from user B. After all, that's what the OS does.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-Share Alike 2.5 License.