现实世界只不过是反射出了更高层次的世界的阴影 — 柏拉图

计算机世界中的许多事物是现实世界的一个投影,现实中所见的许多模式/概念在计算机世界里都能找到

权限作为现实世界随处可见的概念,在我们谈论私有制所有权时,时常会谈及权限,在计算机世界中,权限在许多系统中举足轻重

曾记否,qq里隐身对她可见,怕她看不见,下线又上线,却依旧被视而不见
曾记否,好好的一个熟人,说做微商就做微商,痛心疾首,火速拉黑

上述的这些,都是利用权限系统的典型案例,在qq隐身案例中,你对女神隐身可见,实际上是赋予了她可以看到你的隐身状态(真实状态)的权限;当然你也赋予了人家伤害你的权限

在朋友圈中的案例中,你把微商拉到了黑名单用户组,这样一来,他们就没有看到你的状态的权限,你也看不到他的刷屏

下边我们将以几个案例来帮助理解权限系统的概念和设计,这些案例包括:

  • linux操作系统中的权限系统
  • 微信朋友圈中的权限
  • django中的权限机制

近期工作中遇到一个系统设计中关于权限的复杂问题(层级组织),本文是我学习权限系统及对此思考的一个小结

linux中的权限系统

关于权限系统,我们以linux为切入点,它为大多技术人员所熟悉。我们重点关注其中的概念,而对实现细节不做深究

linux是个多用户操作系统,这每个用户有自己的工作空间(home目录)。就好比多人住在一套公寓里,各自有自己的房间。

在linux中一切皆文件,linux鼓励使用文本文件,人和机器能理解文本文件,成为人与机器交流的最好途径。在linux中权限问题往往最终会落到文件的权限上。

如果我们把文件视为一种资源。那么我们会发现 权限往往围绕这些概念:

  • 用户
  • 用户组(群组)
  • 资源
  • 权限类型

如果你对上述概念不大熟悉,推荐阅读鸟哥的Linux 的文件权限与目录配置

上边几个概念中,鸟哥对用户组的解释很棒(意义和功能),推荐一读

总结来说,Linux一般将文件关联的身份分为三个类别,分别是 owner/group/others,且三种身份各有 read/write/execute 权限

我们举个本地文件的例子

1
2
ls -l /tmp/test.txt
# -rw-r--r--  1 wwj  wheel  235103  9  7 10:26 /tmp/test.txt

我们在此引用鸟哥文章里的这张图

上述信息表示:文件/tmp/test.txt是文件(-),文件拥有者(wwj)的权限为rw-(读写),文件拥有群组(wheel)的权限为r--(读),其他人的权限为r--(读)

如果你想改变文件属性与权限,可以使用:

  • chgrp :改变文件所属群组
  • chown :改变文件拥有者
  • chmod :改变文件的权限

有了群组/资源/用户这些概念,之后我们就可以这样表达权限了:

  • A用户有资源B的可读权限®
  • 群组X有资源Y的可读权限®

朋友圈中的分组与权限

在用户/群组/资源/权限类型的视角下,我们可以这样理解微信朋友圈的分组功能:

你半夜回家发了一条: 今天大学聚会很开心,为了让没到现场的同学也看到聚会情况,于是附上了聚会照片,你怕被小伙伴诟病为天天晒吃的,于是决定这条消息只对大学同学组可见,这样只有在大学同学组(群组)里的同学(用户)才能看到(可读权限)聚会消息(资源)

RBAC

如果我们进一步抽象,我们便总结出了基于角色的访问控制(Role-Based Access Control,RBAC)

Who对What进行How操作

我们可以看到这种模式:

大学同学组里的同学(who)才能看到(how)聚会消息(what)

RBAC认为权限授权实际上是Who、What、How的问题

在RBAC模型中,who、what、how构成了访问权限三元组,也就是Who对What进行How的操作,各个要素的含义如下:

  • Who:权限的拥用者或主体(如User、Group、Role)
  • What:权限针对的对象或资源(Resource)。
  • How:具体的权限

特点

模型中概念与实际系统紧密对应。RBAC模型中的角色、用户和许可权等概念都是实际系统实际存在的实体,便于设计者建立现存的或待建系统的RBAC模型

分治的思路

  • 我们要分割这些问题来讨论(分析的思路/分治)
    • 用户与角色的指派
    • 角色与权限的指派
    • 为定义角色的继承 进行的角色与角色的指派。

上述这些活动都要求把用户和权限联系起来。多数情况下它们最好由不同的管理员或管理角色来做。对角色指派权限是典型的应用管理者的职责(类似元角色)

概念解释

  • Group:用户组,权限分配的单位与载体。组可以包括组(以实现权限的继承)(适合用来处理层级问题),也可以包含用户,组内用户继承组的权限。User与Group是多对多的关系。Group可以层次化,以满足不同层级权限控制的要求。 (漂亮解决了我的问题)
    • 部门Department或组织Organization,都可以对应到Group
  • Role:Role和User关系的左右两边都是Many-to-Many关系,角色是为了完成各种工作而创造,用户则依据它的责任和资格来被指派相应的角色,角色配置成其完成任务所需要的最小的权限集
  • 许可表(PERMISSIONS)包括许可标识、许可名称、受控对象、操作标识。许可表给出了受控对象与操作算子的对应关系。*

其他笔记

  • RBAC都是基于关系模型
  • 资源是受控对象
  • RBAC模型支持数据抽象原则和继承概念
  • RBAC模型没有提供操作顺序控制机制

Django中的权限机制

这部分主要参考Django权限机制的实现

如果你对Django熟悉(不熟悉的话参考你所用web框架的权限机制),可以把这部分理解为以Django为例,解释如何把权限概念用于web项目

在web应用中,权限机制能够约束用户行为,控制页面的显示内容(想想你的朋友圈和各种论坛的会员机制),也能使API更加安全和灵活(django-rest-framework中)

Django中用user, grouppermission完成了权限机制(和linux很像),这些概念,我们在前文中阐述清楚了,这个权限机制是将属于model的某个permission赋予user或group,可以理解为全局的权限(ps:如果你需要更细分的权限机制,可以试试:django-guardian

Django的权限项

Django用permission(如前文说的许可表)对象存储权限项(How),每个model默认都有三个permission,即add model, change model和delete model,在admin中你可以看到,当然我们也可以手动添加其他权限项,不过值得注意的是权限是针对model的,而不是instance的!

为一个用户添加权限,既可以在view里做(编码),也可以由管理员(Role)在admin里做(不需要编码)

使用权限

  • 在view中,使用装饰器来验证权限:@permission_required('car.can_drive')
  • 在模板中,当前登录用户的权限存储在模板变量 {{ perms }}

todo

  • LDAP 认证和权限

参考

相关概念

django

linux