现实世界只不过是反射出了更高层次的世界的阴影 — 柏拉图
计算机世界中的许多事物是现实世界的一个投影，现实中所见的许多模式/概念在计算机世界里都能找到
权限作为现实世界随处可见的概念，在我们谈论私有制、所有权时，时常会谈及权限，在计算机世界中，权限在许多系统中举足轻重
下边我们将以几个案例来帮助理解权限系统的概念和设计，这些案例包括：
近期工作中遇到一个系统设计中关于权限的复杂问题（层级组织），本文是我学习权限系统及对此思考的一个小结
关于权限系统，我们以linux为切入点，它为大多技术人员所熟悉。我们重点关注其中的概念，而对实现细节不做深究
linux是个多用户操作系统，这每个用户有自己的工作空间(home目录)。就好比多人住在一套公寓里，各自有自己的房间。
在linux中一切皆文件，linux鼓励使用文本文件，人和机器能理解文本文件，成为人与机器交流的最好途径。在linux中权限问题往往最终会落到文件的权限上。
如果我们把文件视为一种资源。那么我们会发现 权限往往围绕这些概念：
如果你对上述概念不大熟悉，推荐阅读鸟哥的Linux 的文件权限与目录配置
上边几个概念中，鸟哥对用户组的解释很棒（意义和功能），推荐一读
总结来说，Linux一般将文件关联的身份分为三个类别，分别是 owner/group/others，且三种身份各有 read/write/execute 权限
我们举个本地文件的例子
|
|
我们在此引用鸟哥文章里的这张图
上述信息表示：文件/tmp/test.txt是文件(-)，文件拥有者(wwj)的权限为rw-(读写)，文件拥有群组(wheel)的权限为r--(读)，其他人的权限为r--(读)
如果你想改变文件属性与权限，可以使用：
有了群组/资源/用户这些概念，之后我们就可以这样表达权限了:
在用户/群组/资源/权限类型的视角下，我们可以这样理解微信朋友圈的分组功能：
你半夜回家发了一条: 今天大学聚会很开心，为了让没到现场的同学也看到聚会情况，于是附上了聚会照片，你怕被小伙伴诟病为天天晒吃的，于是决定这条消息只对大学同学组可见,这样只有在大学同学组(群组)里的同学(用户)才能看到(可读权限)聚会消息(资源)
如果我们进一步抽象，我们便总结出了基于角色的访问控制(Role-Based Access Control，RBAC)
Who对What进行How操作
我们可以看到这种模式：
大学同学组里的同学(who)才能看到(how)聚会消息(what)
RBAC认为权限授权实际上是Who、What、How的问题
在RBAC模型中，who、what、how构成了访问权限三元组,也就是Who对What进行How的操作，各个要素的含义如下：
模型中概念与实际系统紧密对应。RBAC模型中的角色、用户和许可权等概念都是实际系统实际存在的实体，便于设计者建立现存的或待建系统的RBAC模型
上述这些活动都要求把用户和权限联系起来。多数情况下它们最好由不同的管理员或管理角色来做。对角色指派权限是典型的应用管理者的职责（类似元角色）
权限的继承)（适合用来处理层级问题），也可以包含用户，组内用户继承组的权限。User与Group是多对多的关系。Group可以层次化，以满足不同层级权限控制的要求。 （漂亮解决了我的问题）
这部分主要参考Django权限机制的实现
如果你对Django熟悉（不熟悉的话参考你所用web框架的权限机制），可以把这部分理解为以Django为例，解释如何把权限概念用于web项目
在web应用中，权限机制能够约束用户行为，控制页面的显示内容（想想你的朋友圈和各种论坛的会员机制），也能使API更加安全和灵活（django-rest-framework中）
Django中用user, group和permission完成了权限机制(和linux很像)，这些概念，我们在前文中阐述清楚了，这个权限机制是将属于model的某个permission赋予user或group，可以理解为全局的权限（ps：如果你需要更细分的权限机制，可以试试：django-guardian）
Django用permission（如前文说的许可表）对象存储权限项（How），每个model默认都有三个permission，即add model, change model和delete model，在admin中你可以看到，当然我们也可以手动添加其他权限项，不过值得注意的是权限是针对model的，而不是instance的！
为一个用户添加权限，既可以在view里做（编码），也可以由管理员（Role）在admin里做（不需要编码）
@permission_required('car.can_drive'){{ perms }} 中此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。