悦库企业网盘5.3版本发布了。本期主要优化数据库和升级逻辑，修复了Linux系统无法设置定时任务等问题，优化用户体验。

此外，本期还修复了用户近期反馈的问题，感谢广大用户对悦库网盘的支持。

欢迎大家下载使用，遇到问题可以随时反馈，我们会积极修复。点击加QQ群：450448657 。

一、版本更新内容​

1、优化数据库和升级逻辑。

2、修复Linux系统无法设置定时任务的问题。

3、修复创建空间提示错误的问题。

4、修复文件属性页面权限为空的问题。

5、修复用户只有下载权限，虚拟盘中可以上传的问题。

6、修复分享的链接无法下载的问题。

二、下载地址​

点击下载服务端

客户端下载

Web端登录网盘，点击左下角用户名称，即可在个人信息栏中看到下载入口。

三、主要界面​

▼ 分享给同事：用户可以将文件和文件夹发送给同事，并且可以添加留言。

▼ 我的消息：用户可以查看收到的文件和留言等消息。

▼ 全文检索：可以根据文件内容搜索文件，并展示文件列表，内容搜索同时匹配文件名称和内容。

▼ 系统回收站：系统管理员在后台拥有二级回收站，可以恢复他人误删的文件。

▼ 空间视图右键菜单：支持视图类型、排列方式、刷新和新建空间等常用操作，用户操作更加方便快捷。

3.1 概念​

Role-Based Access Control (基于角色的访问控制)，简称RBAC。是一种基于角色并使用角色中预先定义的策略(Policy)对主体操作对象进行验证的访问控制方式。NIST于1992年发表论文对RBAC标准进行了定义。

什么是角色？在企业中访问控制的范围通常取决于员工所扮演的角色，角色中包含企业已确认的职责、责任和资格的规范，例如：软件公司中的角色包括工程师、设计师、商务人员等，每一种角色根据其包含的职责通常有不同的访问范围。

主体是指用户或组织。

对象是系统资源，如⽂件、设备、程序、网络等。

操作是主体请求对对象执⾏的功能。例如文件操作，包括对文件的读、写、编辑、删除、复制、执⾏和修改等。

策略(Policy)是一组访问规则。用于定义角色对对象可以执行某种操作。例如策略：允许商务人员对文件"客户资料.xlsx"执行读操作，这里商务人员是一个角色，"客户资料.xlsx"是对象，读是操作。

3.2 工作原理​

下图展示了基于RBAC访问控制机制下，主体（小明）访问对象的工作原理：

1. 主体请求访问对象。

2. RBAC访问控制机制首先获取主体的角色，然后根据角色中的策略对该请求进行授权验证。

3. 如果验证通过，则可以访问对象。

在现实世界的例子：

”我作为一名管理员，希望授权小明(商务人员)，读取文件“客户资料.xlsx”。

访问主体是“小明”，主体的角色是商务人员。

对象是 “客户资料.xlsx”。

实现方式

1. 新建一个角色为“商务人员”。

2. 假如角色的策略定义格式为：allow {角色} {对象} {操作}，则定义以下策略：

   allow {商务人员} {客户资料.xlsx} {读取}
   

3. 设置“小明”的角色为“商务人员角色”。

在满足以上条件后，当“小明” 读取文件“客户资料.xlsx”时，RBAC访问控制机制就可以根据主体角色，使用管理员预先定义的策略(Policy)对这次访问进行验证，如果验证结果通过，就可以读取。对于其他新增商务人员的授权也只需要设置角色为“商务人员”即可访问商务人员对应的文件，如果有人员离职，也只需要将离职人员移除角色即可，这样就通过角色实现了人员和访问资源的解耦，提高了权限配置的效率。

3.2 数学描述​

为了阐明概念，我们对RBAC给出⼀个简单的数学描述。这里的主体s指“用户”，例如"小明"。事务t是指操作+对象，例如：读取文件“客户资料.xlsx”。

主体s的活动角色，活动角色是主体当前正在使用的角色：

主体s的授权角色，每个主体可以授权多个角色：

每个⻆⾊都可以被授权执⾏⼀个或多个事务：

主体执⾏事务，当且仅当主体(if and only if)主体s可以在当前时间执⾏事务t ，函数exec(s,t)为真，否则为假：

三个基本原则

数学符号解释

∀ 任意，相当于every。当∀后面跟有以x为变量的公式时，写作(∀x)，读作“任意x”。例如，(∀a)a≥6表示所有的a都不小于6。

⇒ 推出，A⇒B意味着如果A为真，则B也为真；如果A为假，则对B没有任何影响。

≠ 不等于。

Ø[fai] 空集， 指不含任何元素的集合。

⊆ 包含于，表示一个集合中的元素全部是另一个集合里的元素。

1. ⻆⾊分配：只有当主体选择或分配了⻆⾊时，主体才能执⾏事务。系统上的所有其他⽤⼾活动都是通过事务进⾏的，因此所有活跃⽤⼾都需要有⼀些活跃的⻆⾊。

   公式解释：执行事务成功 only if 活动角色不为空。

2. ⻆⾊授权：⼀个主体的活动⻆⾊一定是已授权的角色：

   公式解释：活动角色是已授权角色的子集。

   $$∀s:subject,(AR(s) ⊆ RA(s))$$

3. 事务授权：只有当事务被授权为主体的活动⻆⾊时，主体才能执⾏该事务：

   公式解释：执行事务成功 only if 事务包含已授权的活动角色。

   $$∀s:subject,t : tran, (exec(s,t) ⇒ t ∈TA(AR(s))).$$

对于 (1) 和 (2)确保⽤⼾只能执⾏他们被授权的事务。请注意，因为条件是“only if”，所以允许对事务执⾏施加额外限制的可能性。也就是说，不能仅仅因为它在TA(AR(s))中就保证事务是可执⾏的，TA(AR(s))是主体的活动⻆⾊可以执⾏的事务。例如，主管⻆⾊的实习⽣可能被分配“主管”⻆⾊，但对其⽤⼾⻆⾊施加了限制，将可访问的事务限制为主管⻆⾊通常允许的事务的⼦集。

4. 强制控制⽤⼾必须通过某种验证函数访问对象的模式：

   公式解释：执行事务成功 only if access(AR(s),f,o, x)

   access(AR(s),f,o, x) 表示是否允许活动⻆⾊中的主体使⽤函数f对对象o执行x操作 ，其中x指某些模式集，例如：读r、写w、执行x。

例如，在医院环境中，使⽤这条策略可能是合适的。可以为医⽣提供对处⽅⽂件的读/写权限，⽽药剂师只有读权限。 （回想⼀下，单独使⽤前4个原则需要绑定事务中的f和o，并且只控制对事务的访问。）使⽤ (4)可能有助于强制执⾏机密性要求。

RBAC 的另⼀个⽤途是⽀持完整性。完整性已以多种⽅式定义，但完整性的⼀个⽅⾯要求数据和流程只能由授权⽤⼾以授权⽅式进⾏修改。对于许多实际系统来说，这似乎是⼀个合理的安全⽬标，并且 RBAC 应该适⽤于此类系统。

通常，确定数据是否仅以授权⽅式修改的问题可能与进⾏修改的事务⼀样复杂。出于这个原 因，实际的⽅法是对事务进⾏认证和信任。如果必须信任事务，则可以将访问控制直接合并到每个事务中。

要求系统通过 (4) 中使⽤的访问函数来控制事务程序对对象的访问可能是⼀种有⽤的冗余形式，但它可能会涉及⼤量开销，从⽽在执⾏完整性要求时获得有限的好处。

因此，在 RBAC 中包含对对象访问控制功能的事务将在某些应⽤程序中有⽤。

3.2 与DAC比较​

在多数企业中，员工通常并不拥有其允许访问文件的“所有权”，而是仅拥有基于自己的角色的文件的“访问控制权”。

DAC模型允许系统用户访问拥有权限的任意文件，并能够将其现有的访问权限直接(或者间接)传递给任何其他用户，而无需系统管理员干预，这是不安全的。

RBAC模型的系统⽤⼾不能⾃⾏决定将权限传递给其他⽤⼾，这是 RBAC 和 DAC 之间的根本区别。

3.3 使⽤ RBAC 集中管理安全性​

RBAC 是灵活的，因为它可以在策略和结构⽅⾯具有组织特征。 RBAC 最⼤的优点之⼀是它⽀持的管理功能。

⼀旦⻆⾊的事务在系统中建⽴，这些事务往往会保持相对恒定或随时间缓慢变化。管理任务包括授予和 撤销系统内指定命名⻆⾊集的成员资格。

当新⼈进⼊组织时，管理员只需将成员资格授予现有⻆⾊。当⼀个⼈在组织内的职能发⽣变化时，可以 轻松删除其现有⻆⾊的⽤⼾成员资格并授予新⻆⾊。最后，当⼀个⼈离开组织时，所有⻆⾊的所有成员资格都将被删除。对于经历⼤量⼈员流动的组织，RBAC是唯⼀合乎逻辑的选择。

此外，⻆⾊可以由多个子⻆⾊组成。例如，医院里有 治疗师、实习生 和 医生⻆⾊。图2描述了这种关系的 ⼀个⽰例。

通过授予成员医⽣⻆⾊，这意味着可以访问实习⽣和治疗师定义的所有事务，以及医⽣的事务。通过授予成员实习⽣⻆⾊，意味着实习⽣和治疗师⽽不是医⽣的事务。但是，通过授予成员治疗师⻆⾊，则仅允许访问治疗师⻆⾊下允许的资源。

3.4 最⼩特权原则​

最⼩特权原则已被描述为对于满⾜完整性⽬标很重要。最⼩权限原则要求⽤⼾获得的权限不超过执⾏⼯作所需的权限。确保最低权限需要确定⽤⼾的⼯作是什么，确定执⾏该⼯作所需的最低权限集，并将⽤⼾限制在具有这些权限的域中。

3.5 职责分离​

系统管理员可以使⽤ RBAC 机制来执⾏职责分离策略。职责分离在阻⽌欺诈⽅⾯被认为是有 价值的，因为如果存在各种与⼯作相关的能⼒之间的协作机会，就会发⽣欺诈。职责分离要求对于特定的事务集，不允许单个个⼈执⾏该集中的所有事务。最常⽤的⽰例是启动⽀付和授权⽀付所需的单独事务。任何⼀个⼈都不应该能够同时执⾏这两项事务。

职责分离是实际系统中的⼀个重要考虑因素。在实际情况下，只有某些事务需要根据职责分离要求进⾏限制。例如，我们希望“授权⽀付”的事务受到限制，但“向管理员提交建议”的事务不会受到限制。

职责分离可以是静态的或动态的。可以简单地通过将个⼈分配给⻆⾊并将事务分配给⻆⾊来确定是否符合静态分离要求。更困难的情况是动态职责分离，只有在系统运⾏期间才能确定是否符合要求。动态职责分离背后的⽬标是在操作中提供更⼤的灵活性。考虑发起和授权付款的情况。静态策略可能要求任何可以作为⽀付发起⼈的个⼈也不能作为⽀付授权⼈。这可以通过确保执⾏发起者⻆⾊的⼈也可以执⾏授权者⻆⾊来实现。这样的策略对于商业⽤途来说可能过于僵化，使得安全成本⼤于没有安全的预期损失。

3.6 总结和结论​

在⼯业界和⺠间政府的许多组织中，最终⽤⼾并不“拥有”他们被允许访问的信息。对于这些组织，公司或机构是系统对象的实际“所有者”，DAC可能不合适。基于⻆⾊的访问控制 (RBAC) 是⼀种⾮⾃主访问控制机制，它允许并促进对组织特定安全策略的集中管理。

访问控制决策通常基于个⼈⽤⼾作为组织的⼀部分所承担的⻆⾊。⻆⾊指定⼀个⽤⼾或⼀组⽤⼾可以在组织的上下⽂中执⾏的⼀组事务。 RBAC 提供了⼀种命名和描述个⼈与权利之间关系的⽅法，提供了⼀种满⾜许多商业和⺠间政府组织的安全处理需求的⽅法。

已经描述了各种形式的基于⻆⾊的访问控制，其中⼀些在当今的商业系统中使⽤，但是没有普遍接受的 定义或包含 RBAC 的正式标准。因此，这些系统的评估和测试程序尚未像符合可信计算机安全评估标准 的系统那样建⽴。本⽂提出的 RBAC 的要求和访问控制策略可以作为基于⽤⼾⻆ ⾊的访问控制的通⽤定义的基础。

参考链接​

基于角色的访问控制(RBAC) 原始论文

克拉克-威尔逊模型

RBAC就像它本来的样子

Mandatory Access Control( 强制访问控制 )，简称MAC, 是在计算机安全领域中的一种访问控制类型，操作系统通过这种访问控制来限制主体对对象执行操作的能力。在操作系统的情况下，主体通常是进程；对象是诸如文件、目录、网络端口、IO 设备等。主体和对象各有一组安全标签。每当主体尝试访问对象时，操作系统内核强制执行的授权策略会检查这些安全标签并决定是否可以进行访问。任何主体对任何对象的任何操作都会根据一组授权策略进行简称，以确定该操作是否被允许。

MAC的成熟实践主要有Linux的SELinux和Windows的MIC，以下我们以SELinux为参考，讲解MAC模型。

2.1 SELinux​

2.1.1 什么是SELinux​

安全增强型 Linux（SELinux）是一种采用安全架构的Linux 系统，它能够让管理员更好地管控哪些人可以访问系统。它最初是作为 Linux 内核的一系列补丁，由美国国家安全局（NSA）利用 Linux 安全模块（LSM）开发而成。

SELinux 于 2000 年发布到开源社区，并于 2003 年集成到上游 Linux 内核中。

2.1.2 为什么需要SELinux​

回顾第1章我们介绍的权限三要素为：主体对哪个对象拥有什么访问策略。

在DAC模型中，对资源访问的主体是用户，没有对进程的行为做任何限制，假如当前用户是root组，该用户启动了Apache+MySQL的服务端程序对外提供WEB服务，如果黑客可以通过漏洞成功劫持该进程，则黑客可以对计算机中所有资源做任意操作，比如直接修改MySQL服务中的各种业务数据，这是非常严重的后果。

在SELinux中，对资源访问的主体为进程，在上面的例子中，我们可以将Apache进程的访问资源限定在指定的数据目录如 /data/apache中，这样即使黑客劫持Apache进程，即使root用户，也只能访问 /data/apache这个目录，没有权限访问MySQL的数据，无法破坏业务数据，因此提高了系统的整体安全性。

2.2.3 SELinux 如何工作​

SELinux 为系统上的应用程序、进程和文件定义了访问控制。它使用安全策略（一组策略告诉 SELinux 什么可以访问或不可以访问）来强制执行策略允许的访问。

当称为主体的应用程序或进程请求访问对象（如文件）时，SELinux 会检查访问向量缓存，简称AVC(Access Vector Cache)，其中缓存了主体和对象的权限决策。如果 SELinux 无法根据缓存的权限做出访问决策，它会将请求发送到安全服务器。安全服务器检查应用程序或进程和文件的安全上下文,从 SELinux 策略数据库应用安全上下文，然后授予或拒绝许可，决策作出后，会加入到AVC中。

SELinux 是一个标签系统，每个进程、文件/目录对象都有一个标签，甚至网络端口、设备和可能的主机名也有分配标签。我们编写策略来控制进程标签对对象标签（如文件）的访问，称之为策略(policy)。内核(kernel)负责执行策略，而这种强制执行就称为强制访问控制，简称MAC(Mandatory Access Control)。

2.2 概念​

SeLinux的MAC实施由三个相对独立的子模型组成：分别为TE、MLS、MCS，我将详细介绍这三种模型。在学习下面三种模型之前，我们需要明确两个基本语言概念：类型(Type)和类别(Category )的区别？

汉语词典的解释：

类型 是由各种具有共同特征的事物或现象所形成的种类。

类别 是按种类的不同而做出的区别。

类型可以通过共同特征来准确识别对象，是客观存在的事实，是严谨的。而类别是一组主观认为的相似属性的对象，并不一定是客观事实，不严谨。

举个例子

1. 路边有3只动物，我将它们的类型定义为猫，则它们必须是猫，是严谨的客观事实，所有人都能根据类型识别出它们到底是不是猫。还是这3只动物，我将它的类别划分为“活泼的”和“安静的”，但这个类别只是我主观观察的结果，是随意的，不一定是事实。

2. 文件夹下有10个文件，我将它们的类型定义为图片，并将它们的类别划分为“自然风光”和“海洋世界”。这里的图片类型是客观事实，划分的图片类别是主观定义。

因此当你需要对一些对象进行分类时，可以优先使用类型划分，这样比较准确，然后再考虑使用类别划分。

2.3 TE 模型​

SELinux 主要模型称为类型强制，简称TE (Type enforcement) 。基本上，这意味着我们根据进程的类型定义进程的标签，并根据其类型定义文件系统对象的标签。

举个例子

以下充满活力和趣味的CAT/DOG系列示例来自RedHat工程师Daniel J Walsh和交互设计师Máirín Duffy，本文作者进行了一些中国化处理，感谢原文作者的优秀创作。

注：狗粮盘子上的字母Fido[fai.dow]是一只意大利流浪狗的名字，于1941年被一位名叫索里亚尼的砖窑工人收留，后来的两年间，Fido每个工作日都在公交站接送索里亚尼上下班。1943年第二次世界大战间，有一天意大利遭到盟军轰炸，索里亚尼阵亡，那天晚上，Fido 像往常一样出现在公交车站，但没有看到索里亚尼下车，Fido 后来回家了。但此后的十四年直到它去世的那一天，它每天都去车站，等着索里亚尼下车。

有一个叫做"宠物餐厅"的SELinux操作系统，有CAT和DOG两种动物，我们将CAT和DOG定义为进程类型，这是主体类型。

我们有它们想要与之交互的对象，称之为食物。为食物添加类型，CAT_CHOWN和DOG_CHOW，这是对象类型。

作为一名策略制定者，我会说猫有权限吃CAT_CHOWN食物，狗有权限吃DOG_CHOW食物。

在 SELinux 中，我们会在策略中编写此策略:

allow CAT CAT_CHOWN eat;

allow DOG DOG_CHOW eat;

使用这些策略，Linux内核将允许CAT进程吃标记类型为CAT_CHOWN的食物，而狗吃标记类型为DOG_CHOW的食物。

但是在 SELinux 系统中，默认情况下没有设定权限的所有访问对象的行为都会被拒绝。这意味着如果 DOG进程试图吃掉CAT_CHOWN ，内核会阻止它。

同样，CAT也不允许吃DOG_CHOW。

同理，在人类的网上银行生产环境中的例子：

我们将 Apache 进程标记为httpd_t类型 ，并将 Apache 的访问数据内容标记为httpd_sys_content_rw_t类型。假设我们将储蓄卡数据存储在标记为msyqld_data_t的 MySQL 数据库中。如果 Apache 进程被黑客入侵，黑客可以控制httpd_t 进程并被允许读写内容httpd_sys_content_rw_t。但是即使进程以 root 身份运行，黑客也不会被允许读取信用卡数据 ( mysqld_data_t )。

在这种情况下，SELinux 已经减轻了入侵带来的后果，提高了安全性。

2.4 MCS 模型​

多类别模型，简称MCS (Multi-Category Security) ，是一种访问控制机制，是对TE的增强。用户使用类别分别标记进程和文件后，进程只能访问与其类别相同的的文件。

MCS用于进一步限制自由访问控制( DAC ) 和类型强制( TE ) 逻辑，假设现有的DAC和TE策略已允许访问 ，则只有有权访问此类别的用户才能访问标有该类别的文件。MCS 的目的是维护系统上的数据机密性。

举个例子

在TE模型的例子中，我们将CAT和DOG定义为主体类型，并且只能访问指定资源类型的CAT_CHOWN 和DOG_CHOW。

现在，如果有多个 DOGS（如Fido和Spot），但Fido比较调皮，偷吃了Spot的DOG_CHOW，因此我们要阻止Fido吃Spot的DOG_CHOW：

如果使用TE模型，我们需要分别为Fido这个主体和属于它的资源DOG_CHOW创建新类型，如果要阻止其他DOG的类似行为则需要为每个DOG和他们的DOG_CHOW创建新类型。但是随着后续DOGS数量的增加，这样的方式很快将变的混乱，因为一般情况所有的狗都拥有吃DOG_CHOW的权限，但却需要为它们中每一个调皮者定义不同的新类型，显然调皮者是独立权限不能继承DOG类型的通用权限了。理想情况下，我们是希望每一只DOG都只能吃属于自己的DOG_CHOW。

为了解决这个问题，我们开发了一种新的执法形式，我们称之为多类别安全 (MCS)，这是基于TE的一种执法延伸。在 MCS 中，我们在TE基础上添加了标签的另一部分，将其附加应用于 DOG 主体和 DOG_CHOW 资源。现在我们将 DOG 进程标记为DOG:random1 (Fido) 和DOG:random2 (Spot)。

我们将狗食物标记为DOG_CHOW:random1 (Fido)和DOG_CHOW:random2 (Spot)：

MCS 策略为：如果类型强制策略正常且随机 MCS 标签完全匹配，则允许访问，否则拒绝访问，于是：

Fido (DOG:random1) 试图吃CAT_CHOW:food被TE拒绝。

Fido (DOG:random1) 被允许吃DOG_CHOW:random1。

Fido (DOG:random1) 被拒绝吃 spot ( DOG_CHOW:random2 ) 的食物。

同理，在人类的虚拟机生产环境中的例子：

如果我们有一台运行大量虚拟机的服务器，其中一个被黑客入侵，我想防止它攻击其他虚拟机和虚拟机镜像。

在TE中，KVM虚拟机被标记为svirt_t并且镜像被标记为svirt_image_t。我们有策略说svirt_t可以读取/写入/删除标记为svirt_image_t 的内容。

libvirt(虚拟机管理工具)不仅实现了TE分离，还实现了 MCS 分离，当 libvirt 即将启动虚拟机时，它会选择一个随机的 MCS 标签，如s0:c1,c2，然后将svirt_image_t:s0:c1,c2标签分配给虚拟机需要管理的所有数据内容。 最后，它以svirt_t:s0:c1,c2的形式启动虚拟机，SELinux 内核控制svirt_t:s0:c1,c2只能写入匹配的svirt_image_t:s0:c1,c2标签，不能写入其他任意标签如svirt_image_t:s0:c3,c4，即使虚拟机被黑客以root身份劫持。

2.5 MLS 模型​

多层级模型，简称MLS(Multi-Level Security) ，是指强制实施Bell-LaPadula模型的安全方案，主要思想是根据数据层级的差别来控制流程。

Bell-LaPadula模型 (BLP) 是一种状态机模型，用于在政府和军事应用中实施访问控制，它由 David Elliott Bell和 Leonard J. LaPadula 在Roger R. Schell的指导下开发，以正式确定美国国防部的MLS策略，最终研究论文发表于 1976 年。

在MLS下，用户和进程称为Subject(主体)，文件、设备和系统的其他组件称为Object(对象)。主体和对象都标有安全层级，每个安全层级都由一个敏感度(s0~s15)和一个类别组成。获得机密许可的用户读写机密类别中的文档，但不能查看绝密的文件，而允许写入绝密的文档(在被许可的情况下)，允许读取受限的和未分类的文档。

下图是美国国防部最初设计的许可层级，分为绝密(Top Secret)、机密(Secret)、受限的(Confidential )、未分类(Unclassified)。

下图显示了在“秘密”安全层级下运行的主体与具有不同安全层级的各种对象之间所有允许的数据流。

举个例子

我们现在不讨论不同的狗，而是讨论不同的品种。有一只灰狗和一只吉娃娃。

我们想让灰狗吃任何狗粮，但如果吉娃娃试图吃灰狗狗粮，它可能会窒息。

我们要将 Greyhound 标记为DOG:Greyhound并将其狗粮标记为DOG_CHOW:Greyhound， 并将 Chihuahua 标记为DOG:Chihuahua并将其食物标记为DOG_CHOW:Chihuahua。

使用 MLS 策略，我们让 MLS Greyhound 标签层级大于 Chihuahua 标签，这意味着DOG:Greyhound可以吃DOG_CHOW:Greyhound 和DOG_CHOW:Chihuahua。

但是DOG:Chihuahua不允许吃DOG_CHOW:Greyhound。

当然，DOG:Greyhound和DOG:Chihuahua通过TE仍然被阻止吃CAT_CHOW。

真实世界

有两台 Apache 服务器：一台作为httpd_t:TopSecret运行，另一台作为httpd_t:Secret运行。如果 Apache 进程httpd_t:Secret被黑客入侵，黑客可以读取httpd_sys_content_t:Secret 但无法读取httpd_sys_content_t:TopSecret。

如果运行httpd_t:TopSecret的 Apache 服务器被黑客入侵，它可以读取httpd_sys_content_t:Secret数据以及httpd_sys_content_t:TopSecret。

在军事环境中使用 MLS，可以允许用户查看机密数据，但同一系统上的另一个用户可以读取绝密数据。

参考链接​

强制访问控制(MAC)

Windows强制完整性控制(MIC)

什么是SELinux

SELinux 多层级安全(MLS)

MLS的理论支撑-贝尔-拉帕杜拉模型

有限状态机

可信计算机系统评估标准

SELinux 多类别安全性(MCS)

使用多类别安全性 (MCS) 保护数据机密性

为什么应该为 Linux 容器使用多类别安全性

SELinux 策略实施的可视化操作指南

意大利犬Fido

悦库企业网盘5.2版本发布了。新增分享给同事和我的消息功能，用户可以将文件和文件夹发送给同事，并且可以添加留言，同事可以收到消息提醒，通过消息还可以查看、下载和保存到网盘等操作，极大提高了同事间共享资料的效率。新增全文检索和系统回收站的清理功能，全文检索清理可以保证数据搜索的准确性，清理系统回收站可以释放空间。

此外，本期还修复了用户近期反馈的问题，感谢广大用户对悦库网盘的支持。

欢迎大家下载使用，遇到问题可以随时反馈，我们会积极修复。点击加QQ群：450448657 。

一、版本更新内容​

1、新增我的消息和分享给同事功能。（专业版）

• 您可以将文件分享给同事，并可以添加留言。同事收到消息会有通知，方便及时查阅，并可以将消息中的文件/文件夹保存到网盘。

2、新增全文检索清理功能。（专业版）

3、新增系统回收站清理功能。（专业版）

4、我删除的和我的分享合并到常用工具页面。

5、优化Windows服务端升级流程。

6、修复“外链分享”永久有效期不可用的问题。（用户反馈）

7、修复虚拟盘上传提示“文件数据块与数据校验值不匹配”的问题。（用户反馈）

8、修复虚拟盘上传文件提示“您需要权限来执行此操作”的问题。（用户反馈）

9、修复“我删除的”文件永久删除后，刷新页面内容为空的问题。

10、修复从网页端下载客户端没有绑定服务器IP的问题。（用户反馈）

二、下载地址​

服务端下载入口

https://www.ydisk.cn/page/download.html

客户端下载入口

Web端登录网盘，点击左下角用户名称，即可在个人信息栏中看到下载入口。

三、主要界面​

▼ 分享给同事：用户可以将文件和文件夹发送给同事，并且可以添加留言。

▼ 我的消息：用户可以查看收到的文件和留言等消息。

▼ 常用工具：我删除的和我的分享合并到常用工具页面。

▼ 系统回收站清理：定期清理在系统回收站已过期文件并释放存储空间。

前言​

企业做为一个组织，存在明确的组织架构，由于每个人的职责不同因此对文件的访问范围也不同，随着企业信息化工程进一步完善，员工对文件的访问、共享、传递等需求越来越多，文件的访问便捷性和安全性之间的矛盾越来越大，我们需要学习当前世界流行的主要文件安全访问理论和现有成熟实践，设计一种专业的企业文件访问模型。

今天最著名的安全标准是TCSEC，全称是 Trusted Computer System Evaluation Criteria (可信计算机系统评估标准)，是美国国防部在 20 多年的研究和开发中发展出来的⼀组安全标准，于1985年12月公布，最初只是军用标准，后来延伸至民用领域。

TCSEC 规定了两种类型的访问控制标准：⾃主访问控制 (DAC) 和强制访问控制 (MAC)。DAC 的要求被认为在技术上对商业和⺠⽤政府安全需求以及单级军事系统是正确 的，而 MAC最初⽤于多级安全军事系统，目前这两种访问控制标准都已在Linux系统中实现，我们后续章节将以Linux系统为背景系统讲解这两种模型。

DAC模型​

Linux 系统上基础模型是 DAC, 全称是 Discretionary Access Control (自主访问控制)。

DAC模型是指对象(比如程序、文件、进程)的拥有者可以任意修改或者授予此对象相应的权限，也就是UGO+RWX/ACL权限控制。

权限有三个要素：主体(subject)、对象(object)、策略(policy)，用于表示主体对哪个对象拥有什么访问策略，例如：用户小明对\opt\work文件夹拥有读访问策略。

1.1 文件的UGO+RWX权限控制​

UGO

UGO是User(用户)、Group(用户所属组)和Other(其他用户)的简称：

User是文件的所有者(属主)，一般是创建文件的用户，对该文件具有完全的权限。在一台允许多个用户访问的 Linux 主机上，可以通过文件的所有者来区分一个文件属于那个用户。只有文件的属主和超级权限用户root 修改文件的权限。

Group是文件所属用户组对文件的访问权限(属组)。假如有几个用户合作开发同一个项目，如果每个用户只能查看和修改自己创建的文件就太不方便了，也就谈不上什么合作了。所以需要一个机制允许一个用户查看和修改其它用户的文件，此时就用到组的概念的。我们可以创建一个用户组，然后把需要合作的用户都添加都这个组中。在设置文件的访问权限时，允许这个组中的用户对该文件进行读取和修改。

Other是除了以上两种情况的其他用户对该文件的访问权限。如果我想把一个文件共享给系统中的所有用户该怎么办？通过组的方式显然是不合适的，因为需要把系统中的所有用户都添加到一个组中。并且系统中添加了新用户该怎么办，每添加一个新用户就把他添加到这个组中吗？这个问题可以通过其他人的概念解决。在设置文件的访问权限时，允许其他人户对该文件进行读取和修改。

RWX

RWX则是Read(读)、Write(写)、eXecute(执行)的简称：

每个文件或目录的访问权限都有三组，每组用三位表示，分别为文件属主的读、写和执行三种权限。当用命令 ls -l 显示详细信息时，最左边一列为文件的访问权限。例如：

# ls -al
-rw-------.   1 root root   132 7月   4 2019 .xauthQur1Xx
-rw-------.   1 root root   132 7月   4 2019 .xauthYacMAK
-rw-------.   1 root root   132 3月   8 2020 .xauthykfSZU
drwxr-xr-x.   7 root root   154 10月 21 09:39 ydisk
drwxr-xr-x.   3 root root    69 11月 30 2021 .ydisk

权限列共有 10 个字符，第一个字符为文件类型，后面九个分为三组：第一组为 U(User) ，即文件属主对应的权限；第二组为 G(Group)，即同组用户对应的权限；第三组为 O(Others)，即其他用户对应的权限。每个字符的意义可用下图描述：

权限列的第一个字符（文件类型），-代表普通文件；l代表链接文件；d代表目录文件。

文件与目录的权限有所区别，如下所示：

举例说明：

1. 对文件有 w 权限不能删除文件，需要对文件所在的目录有 w 权限；
2. 对目录有 w 权限不能 cd 进入目录，需要对目录有 x 权限；
3. 对目录有 x 权限，只有在知道文件名并且有 r 权限的时候才能访问目录下的文件；
4. 对目录必须有 x 权限才能 cd 进入到目录，必须有 rx 权限才能使用 ls 列出目录清单
5. 对目录有 w 权限，可以对目录中的任何文件或子目录进行创建、删除或修改操作，即使该文件或目录的所有者是其它用户也是如此。

1.2 文件的ACL权限控制​

ACL的全称是 Access Control List (访问控制列表) ，一个针对文件/目录的访问控制列表。它在UGO权限管理的基础上为文件系统提供一个额外的、更灵活的权限管理机制。它被设计为UNIX文件权限管理的一个补充。ACL允许你给任何用户或用户组设置任何文件/目录的访问权限。

在UGO+RWX权限中，用户对文件只有三种身份，就是属主、属组和其他人，但是在实际工作中，这三种身份实在是不够用，我们举个例子来看看：

根目录中有一个 /project 目录，这是班级的项目目录。班级中的每个学员都可以访问和修改这个目录，老师也需要对这个目录拥有访问和修改权限，其他班级的学员当然不能访问这个目录。需要怎么规划这个目录的权限呢？应该这样：老师使用 root 用户，作为这个目录的属主，权限为 rwx；班级所有的学员都加入 tgroup 组，使 tgroup 组作为 /project 目录的属组，权限是 rwx；其他人的权限设定为 0。这样这个目录的权限就可以符合我们的项目开发要求了。

有一天，班里来了一位试听的学员 st，她必须能够访问 /project 目录，所以必须对这个目录拥有 r 和 x 权限；但是她又没有学习过以前的课程，所以不能赋予她 w 权限，怕她改错了目录中的内容，所以学员 st 的权限就是 r-x。可是如何分配她的身份呢？变为属主？当然不行，要不 root 该放哪里？加入 tgroup 组？也不行，因为 tgroup 组的权限是 rwx，而我们要求学员 st 的权限是 r-x。如果把其他人的权限改为 r-x 呢？这样一来，其他班级的所有学员都可以访问 /project 目录了。

当出现这种情况时，普通权限中的三种身份就不够用了。ACL 权限就是为了解决这个问题的。在使用 ACL 权限给用户 st 陚予权限时，st 既不是 /project 目录的属主，也不是属组，仅仅赋予用户 st 针对此目录的 r-x 权限。这有些类似于 Windows 系统中分配权限的方式，单独指定用户并单独分配权限，这样就解决了用户身份不足的问题。

参考链接​

Linux 权限管理与访问控制详解

了解Linux操作系统的权限管理

Linux DAC权限管理详解

悦库企业网盘5.1版本发布了。新增全文检索功能，可根据内容从数百万文件中快速搜索，并展示文件列表，对匹配内容高亮显示。新增全局文件名称搜索，支持从所有空间中搜索文件，毫秒级返回结果，帮助用户快速查找所需文件。新增系统回收站功能，系统管理员在后台拥有二级回收站，可以恢复他人误删或恶意删除的文件。

此外，本期还修复了用户近期反馈的问题，感谢广大用户对悦库网盘的支持。

欢迎大家下载使用，遇到问题可以随时反馈，我们会积极修复。点击加QQ群：450448657 。

一、版本更新内容​

1. 新增全文检索功能，可以根据文件内容搜索文件。(专业版)
2. 新增全局文件名称搜索功能，可以从所有空间中搜索文件。
3. 新增系统回收站功能，系统管理员拥有二级回收站，可恢复他人误删的文件。（专业版）
4. 优化升级时显示提示框的文案。
5. 修复权限修改提示“ID不存在”的问题。
6. 修复外链分享内容失效的问题。（用户反馈）
7. 修复虚拟盘中无下载权限依旧可以复制到桌面的问题。（用户反馈）
8. 修复路径栏文件夹重名时顺序混乱的问题。
9. 修复组织根用户设置权限显示错误的问题。
10. 修复Linux客户端保存设置后虚拟盘不挂载问题。

二、下载地址​

服务端下载入口

https://www.ydisk.cn/page/download.html

客户端下载入口

Web端登录网盘，点击左下角用户名称，即可在个人信息栏中看到下载入口。

三、主要界面​

▼ 全文检索：可以根据文件内容搜索文件，并展示文件列表，内容搜索同时匹配文件名称和内容。

▼ 系统回收站：系统管理员在后台拥有二级回收站，可以恢复他人误删的文件。

▼ 空间视图右键菜单：支持视图类型、排列方式、刷新和新建空间等常用操作，用户操作更加方便快捷。

分享文件给用户、文件订阅、系统通知、审批流等功能需要消息支持，现在需要建立一种可靠的消息收发机制。

架构​

• 发送者将消息发送到系统消息队列中，发送返回成功。

• 系统消息处理器负责从队列中读取消息并处理，完成后将最终消息放到个人消息收件箱中，然后将消息放入通知消息队列中。

• 通知消息处理器将消息推送给在线用户。

用户场景​

"小明发送一个文件给研发部所有人员。"

实现方法：

1. 小明将文件消息发送到系统消息队列中，发送完成。
2. 消息处理器取出消息，解析内容，读取文件信息，并生成最终的文件消息内容。将消息依次写入研发部所有人员的个人收件箱中，然后将消息放入通知消息队列中。
3. 推送消息处理器将消息推送给在线的研发部人员。在集群化部署场景，用户会随机连接到不同的连接池上，因此每个推送消息处理器只给自己的连接池中的研发部成员推送消息。

随着文件业务模块不断增加，对于文件访问的性能和数据一致性问题之间，我们一直妥协于前者。在生产实践总结中，我们创造了文件事件概念，这种技术在保证访问性能的同时实现文件在各个业务模块中的最终一致性。同时可以实现各个业务模块对文件变动的快速响应能力。

基础概念​

文件仓库是存储文件结构化信息的二维数据表，主要包括文件的详细信息（如名称、大小、时间、创建者等）、树形目录结构信息、索引信息等。

文件业务模块是实现文件管理的附加功能模块，包括文件收藏功能、最近访问功能、全局搜索功能、权限管理功能、分享功能等等。

通常业务模块会根据自身需求冗余一些文件的概要信息，很多业务场景下是需要通过访问文件仓库来获取文件的详细信息。

面临的问题​

业务模块中的文件信息是和仓库关联的，但目前仓库中的文件结构和内容变化不会反应到业务模块中。

例如：

1. 用户在文件仓库中重命名文件，在最近访问、收藏功能模块中查看该文件依然是原来的文件名称。
2. 用户新上传文件，在不能立即在全局搜索中查找，需要等待搜索模块定时索引完成。
3. 用户分享文件链接后，原文件被删除，分享链接依然可访问，但文件已失效。
4. 还有很多场景不一 一列举...

解决文件仓库和业务模块的数据一致性问题，由于业务模块较多且不断增加，使用数据库触发器方式性能太差。

定期检查各个业务模块的数据一致性处理则时效性不满足，全局检查时间很长，资源占用大，实现起来业务耦合度大。

如果不能保证数据一致性，在长时间的文件操作各种操作后，业务模块中必然会出现大量无效文件信息，影响用户使用体验。

文件仓库与业务模块的关联性：

文件事件驱动​

文件事件是指当仓库中文件的结构、信息、内容等发生变化时，由仓库对象负责生成的一种数据结构，其中记录文件的变动行为和相关信息。

例如：仓库中新建文件，会生成新建文件事件，事件信息如下：

当用户操作文件时，服务器收到请求后，由文件操作处理API调用文件仓库完成处理并立即返回用户。文件仓库在操作文件时会生成对应的文件事件推送到事件队列中，防止并发事件处理过多导致系统性能压力，事件处理程序会顺序读取事件并通知到所有文件相关业务模块中，由业务模块自身决定是否对该事件进行处理及如何处理。整体流程如下：

引入文件事件驱动机制后，业务模块不再需要主动探测文件信息的一致性，只需被动处理事件即可，降低了文件仓库的访问压力，提升业务模块对文件变化的响应能力。

文件事件的意义​

文件最终一致性​

业务模块响应来自仓库的文件事件后，可以立即更新模块自身冗余的文件信息，实现文件信息的最终一致性。

从用户角度看就是当文件仓库中的文件被更新后，其他业务模块中的文件也随之立即更新。

文件仓库和业务模块解耦​

业务模块在不直接与文件仓库交互的情况下，具备文件变动响应能力，且对于事件的处理在各个业务模块内部完成。

悦库企业网盘4.9.1版本发布了。支持经典版2.7.2版本数据升级到最新版，如果经典版低于2.7.2版本，需先升级到2.7.2版本。新增文件和空间视图空白处右键菜单功能，文件视图右键菜单支持上传、视图类型、排列方式和新建等多种常用操作。空间视图右键菜单支持视图类型、排列方式、刷新和新建空间等常用操作，用户操作更加方便快捷。

此外，本期还修复了用户近期反馈的问题，感谢广大用户对悦库网盘的支持。

欢迎大家下载使用，遇到问题可以随时反馈，我们会积极修复。点击加QQ群：450448657 。

为了让广大用户充分测试和体验专业版功能，可免费提供30天专业版测试授权，联系商务同事获取。点击添加商务QQ：480247680 。

一、版本更新内容​

1. 新增经典版2.7.2版本数据升级到最新版。
2. 新增文件和空间视图空白处右键菜单功能。
3. 优化最近访问已删除文件提醒功能。
4. 修复专业版文件外链无法预览的问题。
5. 修复当文件被协同编辑锁定时，点击对话框在线打开按钮无效的问题。
6. 修复文件下载失败时临时文件没有释放的问题。
7. 修复LOGO定制重置时无提示的问题。
8. 修复文件夹外链“保存到网盘”提示错误的问题。
9. 修复已删除用户在角色定义中依旧显示的问题。
10. 修复文件编辑保存后，“更新时间”不自动更新的问题。
11. 修复部门管理员可以修改超级管理员密码的问题。
12. 修复超级管理员不能修改性别的问题。
13. 修复只读方式打开文件报错的问题。
14. 修复空间和文件的列表排序方式与菜单的标记不一致的问题。
15. 修复外网登录提示解析API服务应答失败的问题。

二、下载地址​

服务端下载入口

https://www.ydisk.cn/page/download.html

客户端下载入口

Web端登录网盘，点击左下角用户名称，即可在个人信息栏中看到下载入口。

三、主要界面​

▼ 文件视图右键菜单：支持上传、视图类型、排列方式和新建等多种常用操作。

▼ 空间视图右键菜单：支持视图类型、排列方式、刷新和新建空间等常用操作，用户操作更加方便快捷。

▼ 文件链接：用户可分享文件和文件夹链接方便同事直接跳转到目标位置。

▼ 手机端在线预览：单击文件即可预览，支持Word、Excel和PPT等常用office系列办公文件。

▼ 手机端搜索和传输列表功能

▼ 空间配额：管理员可以对空间和用户分配空间大小。

1）空间配额

2）用户配额

▼ 最近访问：最近30天预览和编辑过的文件会加入“最近访问”列表，方便用户查看最近使用过的文件。

▼ 主题切换：用户可选择自己喜欢的外观（悦库蓝、暗黑、赤诚红、叶兰绿、紫藤花、芙蕖粉）。

▼ 动态功能：专业版可查看文件、文件夹和空间的动态，可查看用户对文件进行的所有操作。

▼ 空间转移。

▼ 批量选择、编辑和删除用户功能。

▼ 用户搜索功能。

本提案是对《文件本地编辑提案V1》的补充。

什么是文件本地编辑​

在网盘客户端中直接点击文件自动下载到缓存位置，并使用本地默认程序打开，本地编辑完成后可自动上传到网盘中。

​

问题分析​

问题现象

最近我们收到用户反馈：“本地编辑中连续保存.xlsx格式文件时自动上传的文件低几率损坏现象。”

我们非常重视文件数据可靠性，立即进行确认并讨论解决方案。

问题原因

在文件本地编辑提案V1中，我们说明了文件的上传时机：

文件以读写方式本地打开后，网盘会一直监控文件的保存时间，如果发生变更则自动上传。

文件上传过程是先创建文件任务，加入上传队列，然后再执行上传，这是一个异步操作。当上传任务创建成功后，文件内容随时可能被用户保存，这就导致了上传任务的文件信息和实际上传的文件内容不一致，可能造成最终文件大小或内容信息错误。

由于用户保存文件的行为是不定时发生的，因此不能假设任意时间文件数据是完整可靠的，极端情况下，文件正在写入过程中也可能被上传，这有几率会造成上传的文件不完整。

发布时间

在本提案中我们使用一种对本地编辑文件进行“静止状态”探测的方法，保证上传文件内容的可靠性。

解决方法​

在以上的情景分析中，我们发现问题的根本原因就是文件上传同时用户对其进行保存。如果上传过程中文件处于一种"静止"状态(用户不更新)，那么整个上传流程必然是安全可靠的。

探测静止状态

建立静止的文件，需要对已保存文件进行静止探测，这需要两个固定时间段(8秒/时间段)才能得出结论。

“探测点1”确认文件内容已保存。

“探测点2”确认文件保存后处于静止状态，认为文件在当前时段是静止的，距上次保存后一段时间没有再发生过保存行为。

创建文件快照

文件静止状态确认后，将文件复制到临时目录，复制完成后，需要检测快照复制期间，原文件是否被再次保存，如果已保存则放弃快照。如果没有保存则保留快照，并将快照加入上传队列，由于快照是静止的，所以上传内容的可靠得以保证。

上传静止文件

静止文件快照加入上传后，无论上传结果成功或失败，完成后直接删除即可。

相关阅读​

《文件本地编辑提案V1》