为什么会有 Root 权限？

[exc]

[12101111]

NT 系统和 Fuchsia 系统都没有 root 权限，没有任何一个用户拥有所有的权限
NT 的 Administrators 组是用户可以获得的最高权限，但是仍然非常有限
NT AUTHORITY\LOCAL SERVICE 连联网权限都没有
NT AUTHORITY\NETWORK SERVICE 也就能联网，其他权限还不如标准用户
NT AUTHORITY\SYSTEM 是系统内置服务的最高权限账户，然而并不是系统的最高权限，并且第三方服务想要以 SYSTEM 运行就必须弹 UAC 让 Administrators 组批准
TrustedInstaller 可以随便写入磁盘文件和注册表，但是只有 TiWorker 才能调用

[imn1]

@exc #33
不一定，应该说更大可能是预设了 root 用户和初始密码而已
就是代码归代码，用户表归用户表，只是在用户表预设了 root 用户和初始密码，代码只是读取这个用户并赋予权限，并不是硬生生写在代码里面的

[exc]

@Kinnice 你离职，那么与系统就无关系了，系统应该自动解除账号与你的绑定关系，而不需要 root 账号操作。其他情况下，其他账号，不管是老板、管理员还是其他人操作要你的账号，当然要得到你的同意了，难道不是吗？

[exc]

@12101111 同关注 Fuchsia 系统，可惜还没正式发布，期待中。

实际上未越狱的 Android, iOS 在对待应用程序（即把应用程序看作资源访问者）方面，其权限管理比较符合我的期望，但这两个操作系统，都是类 Unix 系统，并没有从根源上移除 Root 权限。NT 系统我不太了解，就你的描述，也是让用户主动授权给访问者吧，看起来也不错。

[exc]

@imn1 不管怎么说，实现方式都是通过 username=root 或 type=root 或 from admin 来查找，并阻止其他用户注册，这种里的 root 或 admin 或类似的存在，就需要以硬编码的形式编写了。

[luoqeng]

历史原因，容器化时代没啥意义。

我们处在一个很奇怪的时代。不管是最新的手机还是最强大的后台集群，跑着的系统都是一个 40 多年前的 UNIX 的复刻+扩展版，还支持那个时代的 API. 我们当然都不是在用 UNIX 的方式去用系统了，我们不会去 fork 进程然后用 pipe 通信，而是发明了各种各样不见得就更好的并发和通讯方式 —— 然而内核还是要支持像 fork 这种超级 tricky 的系统调用。经典的系统体系早已崩塌，我们要么在废墟上架无数层抽象，要么像 epoll 一样在内核上打洞，而未曾建立一个新的系统体系，这有点像罗马帝国崩溃后的中世纪。


https://www.zhihu.com/question/53232010/answer/135346366

[zypy333]

因为功能分为底层核心和上层应用,安全的层次不一样,底层交给高权限的专业人员,上层交给使用人员,能力越大,责任越大

[digimoon]

我只想知道现在的系统设计为啥会允许 root 这种用户，有破坏系统导致不能正常运行的权限？
如果真要修改系统文件，那么应该要重启到救援模式之类的“另一个系统”里才能操作，简单说就是只要你进了 A 系统那么就不应该有破坏 A 系统的权限

[mytsing520]

从技术层面说，47 楼已经讲明白了。
从逻辑上说，这个世界本身就存在不平等，也不可能存在绝对平等。

[PureWhiteWu]

正是因为有了“无”才会有“有”。希望你能理解这句话。

root 只是一个所有权限的总集，你总会需要一个“所有权限”的集合吧，而且这必须是一个有限集。

root 只是这个所有权限的集合的名字而已。

至于你说的硬编码，你无法避免硬编码所有权限吧？比如可读可写可执行这种。

[FS1P7dJz]

可能有些扩展了
楼主可以了解一下零信任架构
也许可以启发你一下

[shijingshijing]

@digimoon 其实现在的系统就是按照你说的这个思路设计的，不只是操作系统，连 CPU 都按照这个思路改造了。

新的 SoC 一般都有 TrustZone，敏感操作会放到这里执行。

[chocovon]

这是把“用户的操作”和“对系统的访问”进行分离后自然而然产生的一个中间层吧

[exc]

@luoqeng 同意，对于现在的操作系统和编程语言，一样有类似的感觉，如果往深处追索，可能还会触及硬件开发和设计。

[exc]

@zypy333 @mytsing520 我觉得这种说法很像：因为类有基类和继承类，基类负责更通用和基础的事，而继承类则负责一些有个性或差异化的事，越是基类，越要健壮。

这样说自然没错，但前提是，在有类继承关系的编程语言下才有效，以组合为主，如 Go, 或非面向对象的语言，如 Shell，则是无效的，因为前提就不成立了。

换回你说的，功能分为底层核心和上层应用这里，操作系统就一定要这么设计么？根据单一设计原则，我可以把做一个函数设计成一个接口，每个接口都是一个服务，每个服务都可以申请引用其他的服务，在这样的关系里，服务就是图形结构了，上下级关系便自然而然的消失了。

[exc]

@PureWhiteWu root 是一个有限集，但他更是一个可变化的有限集。

这里有两个时间点，A 时间点，Root 这个有限集里有 { "read", "write", "delete" } 权限。B 时间点，Root 有限集里有 { "read", "write", "delete", "exec" } 权限。当一个用户在 A 时间点获得 Root 权限后，到了 B 时间点，他就会自动获得 exec 权限。

这样做合理么？为什么呢？

[exc]

@FS1P7dJz 谢谢，零信任架构，听名字就感觉很有趣。

[exc]

@shijingshijing 挺感兴趣的，求多说点

[xuanbg]

不同于一般的的管理系统，操作系统是需要自举的。

一个业务系统，你可以把管理权限的权限作为一个一般资源，最初的系统管理员可以只是拥有管理权限的权限的一般用户。系统管理员的权限的配置可以通过直接往数据库写入特定的数据来实现。即使错配，也可以通过操作数据库来修正，没啥大不了的。所以 admin 和 user 也没必要两张表，即使 2 张表，该有的问题还是少不了。除非代码写一个超级管理员。我见过很多这种上帝模式的超级管理员，但我认为这就是个超级大后门，弊大于利，不推荐。

但一个操作系统则不行，root 权限必须是先天的，而非可配置的。因为如果错配导致丢失了配置的权限，就没办法通过配置来修复，只能重装系统。这显然不符合我们的预期。

[luoqeng]

再看看这个

现在的状况，就跟我在 如何评价 Midori （ Operating System ）？里写的一样，现在大家只是把 Linux 当成一堆跑在内核态写得巨烂但又勉强能用的底层代码，上面一个深受 Plan 9 影响的 Linux namespace+cgroups container 环境，再上面是 Plan 9 风格的系统抽象和 linux 库+protobuf+stubby 的实现。很不幸，我感觉我们会长期处在这个状态。

https://www.zhihu.com/question/19706063/answer/763200196