phpGACL

phpGACL requires a relational database to store the access control information. It accesses this database via an abstract wrapper called ADOdb. This is compatible with databases such as PostgreSQL, MySQL and Oracle.
phpGACL要求一个关系数据库用来保存访问控制信息。它通过数据抽象层ADODB来访问该数据库，它能兼容PostgreSQL，MySQL和Oracle数据库。
phpGACL is written in the PHP scripting language. It requires PHP 4.2 and above.
phpGACL是用PHP脚本语言编写的，它要求该语言版本号为4.2或以上。
Access Control List administration is performed by a web interface, and therefore it is necessary to have a web server with PHP support, such as Apache.
由于对访问控制列表的管理是通过WEB界面进行的，因此它必须要有一个支持PHP的WEB服务器，如Apache。  

Mike Benoit <ipso@snappymail.ca> is the author and project manager.
Mike Benoit <ipso@snappymail.ca> 是作者和项目管理者.
James Russell ames-phpgacl@ps2-pro.com> and Karsten Dambekalns <k.dambekalns@fishfarm.de> did the documentation.
James Russell ames-phpgacl@ps2-pro.com> 和 Karsten Dambekalns <k.dambekalns@fishfarm.de>制作文档。
　　没想到一时冲动还就真翻了起来，还把东东放上去了，现在想起来都有点不可思议。不过我一向的原则是既然动手了，那就要有个结果，成功了是快乐，失败了 是经验。半途而废的事倒是不会做，但做的速度会越来越慢倒是常见，所以趁着冲动还在，还是多做做，以免后来有人等得心急，骂娘的声音还是少听为妙！:)

Introduction 介绍

Understanding Access Control 
理解访问控制

The best way to explain access control is to use examples with real things rather than trying to relate to concepts.
试着解释访 问控制概念的最好方法就是举个实例，这比纯粹进行概念阐述要好得多。

Han is captain of the Millennium Falcon and Chewie is his second officer. They've taken on board some passengers: Luke, Obi-wan, R2D2 and C3PO. Han needs to define access restrictions for various rooms of the ship: The Cockpit, Lounge, Engines and the external Guns.
Han 是"千年隼"号飞船的船长，  Chewie 是他的助手。船上已经有了几名乘 客： Luke ，  Obi-wan ， R2D2 和 C3PO  ， Han 必须要为船上 不同房间如：驾驶室，休息室，发动机室和武器室限制访问权限。（大家是不是觉得这些名字很熟悉呀？我是看了一半才明白这是电影"星球大战"内的人物！） 
Han says: "Me and Chewie should have access to everywhere, but after a particularly messy hyperdrive repair, I forbid Chewie from going near the Engine Room ever again. Passengers are confined to the Passenger's Lounge."
Han 说："我和Chewie可以到飞船上的任何地方，但在那次糟糕的超光速推进器修理之后， 我不许Chewie再靠近发动机室，而乘客们只能待在休息室里。"

Let's assume from now on that access is Boolean. That is, the result of looking up a person's access to a room is either ALLOW or DENY. There is no middle ground.
让我们假设 从现在开始访问权限都是用布尔值来表示的。也就是说，人们进入房间的权限要么是允许，要么是拒绝，而没有其他中间的值。

If we mapped this statement into an access matrix showing who has access to where, it would look something like this (O means ALLOW, X means DENY):
如果我们将上面Han所说的画出一张表示谁有权访问哪儿的权限表的话，它将会如下表所示 （O表示允许，X表示拒绝）

Who/Where	Cockpit	Lounge	Guns	Engines
Han	O	O	O	O
Chewie	O	O	O	X
Obi-wan	X	O	X	X
Luke	X	O	X	X
R2-D2	X	O	X	X
C3PO	X	O	X	X

The columns list the rooms that Han wants to restrict access to, and the rows list the people that might request access to those rooms. More generally, the "rooms" are "things to control access on". We call these Access Control Objects (ACOs). The "people" are "things requesting access". We call these Access Request Objects (AROs). The people request access to the rooms, or in our terminology, AROs request access to the ACOs.
在上表中，行表示 Han 想要限制访问权限的房间，而列表示要求访问房间权限的人们。衍生开来讲，"房间"就代表 " 控制  权限作用的事物"，我们称之为访问控制对象，即 Access Control Objects (ACOs) 。而"人们"则代表"要求权限的事 物"，我们称之为访问需求对象，即 Access Request Objects (AROs) 。
There is a third type of Object, the Access eXtention Object (AXO) that we'll discuss later. These objects share many attributes and are collectively referred to as Access Objects.
这里还 有一个第三种对象，叫权限扩展对象，即 Access eXtention Object (AXO) ，我们将稍后对它进行讨论。这些对 象共享许多属性，并作为权限对象一起 被 引用。

Managing access using an access matrix like the one above has advantages and disadvantages.
使用权限表 来管理权限有其优点也有其缺点。

Advantages: 优点：

• It's very fine-grained. It's possible to control access for an individual person if necessary.
  它可以做到非常精细。可能的话，它可以对每一个人的权限进行单独的控制。
• It's easy to see who has access to what. The answer is stored in the intersection of the person and the room.
  它也十分容易看出谁有权做什 么，其结果被保存在人们和房间的交叉点上。
• Disadvantages: 缺点：
  • It's difficult to manage on a large scale. 6 passengers and 4 places is fairly simple, but what if there were thousands of passengers and hundreds of places, and you need to restrict access to large groups of them at once, but still retain enough fine-grained control to manage access for an individual? That would mean a lot of fiddly and lengthy adjustment to the matrix, and it's a difficult task to verify that the final matrix is correct.
    它对于大规模权限管理而言是困难的，6个乘客与4个房间相对来说是简单的，但如果是上千个乘客和上百个房间该怎么办呢？你需要马上为他们 分配权限，同时又要保证足够的精细度以便能控制其中每一个人的访问权限。这将意味着对权限表的大量 费事冗长的调整，同时也使得确保该表的正确性变得困难重重。
  • It's hard to summarize or visualize. The above example is fairly simple to summarize in a few sentences (as Han did above), but what if the matrix looked like this?
    它是难以想像和总结的，上面的例子是相当简单的，几句话就可以讲清楚（就象上面Han做得那样）。但如果权限表看得来象下面这样呢？

    Who/Where	Cockpit	Lounge	Guns	Engines
    Han	O	O	O	O
    Chewie	O	X	O	X
    Obi-wan	X	O	X	X
    Luke	O	O	O	X
    R2-D2	X	O	X	O
    C3PO	O	O	X	O

  This matrix is not so obvious to summarize, and it's not clear to the reader why those access decisions might have been made in the first place.
  上表就不能 清楚的总结了，而且它也不能很清楚地让人明白首先为什么要这样设定那些权限。