为什么会有 Root 权限？

• 資深大佬 : wzb0909

  这里的 root 权限不仅仅指 Android, Linux 等操作系统中所说的 Root，也泛指 CMS, 数据库等等系统。

  因为我在开发程序时，发现即使是单用户系统，也要有用户名密码，这时这个唯一的用户就是 Root 用户了，而这时，我就要在程序里作硬编码处理，或在初次运行时输入（其实也要作硬编码处理），我觉得这样写的代码很难看。

  其次多用户系统，拥有 Root 权限的用户会造成可怕的数据风险。

• 主 資深大佬 : exc

  @wzb0909 正因为应用程序拥有 Root 权限，应用程序出了问题才有可能会影响到系统吧。我的意思是，为什么在设计系统时，会设计 Root 这么一个特殊的权限。

• 主 資深大佬 : exc

  @exc 多用户是 unix 的设计，数据库只有 admin 用户，和 root 没关系。

  unix 的应用程序（区别于系统程序）都不应该用 root 用户的名义运行。

  至于你说的硬编码，这是你自己写程序要处理的问题吧。一般来说你可以做成运行启动时配置，也可以做成编译时配置，这都是细节了～

  我感觉我可能没有回答你的问题。但是，目前只能这样～

• 資深大佬 : wzb0909

  @exc 只要设计一把枪，就必然要有一个负责按扳机的人。

  只要设计一把锁，就必然要有一个拿钥匙的人。

  你看有了这个扳机，很不安全，或者有了这把钥匙，很不安全，但没有办法，现实就是不完美的，一切安全问题最终都会落到一个不完美的人类身上。

  另外，便利与安全永远对立，想要多一点便利，就必然少一点安全。大多数情况下，客户、用户都会更看重便利性。

• 資深大佬 : SuperMild

  为什么会有内核态和用户态？
  为什么会有不同的 EL ？
  多看一下操作系统的书吧

• 資深大佬 : systemcall

  admin 和 user 应该放两张表

• 資深大佬 : agagega

  感觉这不像技术问题，而像哲学问题….

• 資深大佬 : Osk

  因为人大于程序。不然的话为啥允许 rm / 为啥允许程序销毁，为啥允许删库。
  所以程序给你 root 账户管理它的一切，而 root 账户的安全就是另一个话题。

  但是，一个数据库的 root 账户凭啥会影响到系统？

• 資深大佬 : nvkou

  因为普通用户的权限不够用

• 資深大佬 : Kinnice

  @nvkou #6 数据库有 system / exec 指令

• 資深大佬 : chinvo

  要有一个上帝吧

• 資深大佬 : zxCoder

  总得需要一个用户来给其他用户分配权限吧

• 資深大佬 : dingwen07

  为啥我们会有个主席？

• 資深大佬 : JoJoJoJ

  @wzb0909 unix 的应用程序不应该以 root 用户的名义运行，否则可能会破坏系统内核。换句话说，正因为存在 root 权限，才存在应用程序可以以 root 权限运行，不是吗？

  单用户程序，总得有一个标记用于指定用户的登录吧，这个标记在我看来，也是硬编码的一种。

• 主 資深大佬 : exc

  @SuperMild 可以在锁上留下更多的钥匙孔呀，一把锁并非只能拥有一个钥匙孔。现在的电子锁，是否可以认为一个指纹等于一个钥匙呢？

• 主 資深大佬 : exc

  @agagega 为什么不能放在一张表里？

• 主 資深大佬 : exc

  @Kinnice 为什么要分普通用户和特殊用户？

• 主 資深大佬 : exc

  这个问题挺有意思的啊
  根据不同用户赋予权限, 是现实使用的需要，是代码设计的结果。
  CMS 系统存在多个使用用户的，一般都有现实的职位、职责区分，让不同人看到、使用不同的功能，这是 CMS 系统的需求。当然可以所有用户都有全部的权限，此时只有把所有人都用同一权限（ ROOT ）就可以；就是说权限分级是可以兼容这种权限不分级的使用的。
  在操作系统上，情况相似，但也有不同。相似是操作系统的确可能是多个人同时使用（服务器）；不同的是，应该也把操作系统上的软件也当做操作系统的用户。此时，权限也是防护电脑的功能。
  在软件的使用上，轻度用户和重度用户对系统的了解和需求是不一样的。ROOT 权限也提供了一种方式，方便用户去定制。潜在的，使用 ROOT 权限也要求使用者对系统足够了解，而不是随意折腾。
  ROOT 权限并不仅仅解决一个问题或者有一个纯粹的出发点，我更倾向于最初简单的设计随着需求变化迭代后，成为针对大多数场景的解决方案。

• 資深大佬 : MozzieW

  @dingwen07 数据安全，用户隐私呢？只要存在你说的这个用户，就永远无法得到保障了吧，而这明明是技术可以解决的呀。

• 主 資深大佬 : exc

  @exc 可以在锁上留下更多的钥匙孔，可以的，因此我上面说了 “便利与安全永远对立，大多数情况下，客户、用户都会更看重便利性”。

  一把锁上有多个钥匙孔，安全性提高了，理论上是一个更完美的产品，奈何缺少客户、用户的支持啊！

  产品做出来，不是裱起来观赏的，要有人用才有价值。

  用户、客户、老板的水平低，不重视安全，这是问题的关键所在，是他们让产品不能表现得又简洁又完美。一些非必要的 root 用户的出现，根源就是用户、客户、老板要求要有这个。

• 資深大佬 : SuperMild

  @MozzieW 嗯嗯，你说的是，可在做编码时，你不觉得针对 Root 的处理很丑陋吗。他就好像一个钉子户一样钉在了程序里，非常的突兀。在软件设计上，这种硬编码也是反模式的一种。同时他的存在，也是数据安全最大的风险。

  你说的这些理由虽然也是理由，但我认为在无 Root 的情况，也是可以解决的。

• 主 資深大佬 : exc

  书读得不多而想得太多

• 資深大佬 : jay777

  @SuperMild 那如果不考虑便利性，我们应当如何设计一个无 root 的程序呢？

• 主 資深大佬 : exc

  @exc 两个方向，1.直接不做会影响安全的 api，2.增加执行高风险 api 的步骤（比如需要步验证、两人验证、要求各种前提条件）。

• 資深大佬 : SuperMild

  @jay777 还请明说，谢谢。

• 主 資深大佬 : exc

  @nvkou 用户使用程序是使用程序提供的服务，用户数据理应只有用户本人可访问和操作，而 root 的存在却可以无视这个规则。那么又为何要保留 Root 呢？

• 主 資深大佬 : exc

  @SuperMild 谢谢，不过个人觉得牺牲这点便利性换取更好的系统安全是值得的。

• 主 資深大佬 : exc

  你说的“硬编码”，是指没有鉴权，代码直接调用 root 么，这个操作跟 linux 直接用 root 登录一个思路

  我只能说用 root 权限写入代码思路不对，或者说高控制代码应该分开写
  当一个系统具有 root 用户权限时，应该同时也有普通用户权限，所以常用操作都应该以一般用户权限写，不创设普通用户而直接使用 root，是偷懒了

• 資深大佬 : imn1

  @exc 这样不是比特殊对待某个用户的做法更干净吗，而且把两个入口彻底分开，还能提高点安全性

• 資深大佬 : agagega

  1.单用户系统，你总要有个用户吧，就算是不需要输入用户名的，但是这个用户也是相当于是个 root 用户
  2.多用户系统，总要有一个用户来管理其他用户吧，此时这个用户就是 root 用户，难道说每一个用户都能删除其他用户?另外有些全用户通用的文件比如 hosts，一个人修改全系统都会受到影响，难道人人都能修改? 还是说修改一次就要重新编译一次系统，为什么不能有个 root 用户可以对它进行修改呢。root 就是上帝模式。

• 資深大佬 : Kinnice

  @exc 另外 cms 系统中，如果有修改系统的名称或者删除其他普通用户账户的需求，随便一个普通用户就可以改 /删除?
  大家都是普通用户你凭什么删除我?或者是有个主管的用户可以对普通用户来进行删除 /改，但是此时这个主管如果是写死的那他就是 root，如果是别人分配的，那分配者就是 root
  所以需要一个 root(管理员)用户来进行操作。

• 資深大佬 : Kinnice

  @imn1 额，路由器激活时、Linux 初次安装时、数据库初次运行时，都有提示输入 Root 或 Admin 的密码吧，这个 root 或 admin 是不是写死在系统代码里的？于我而言，这就是硬编码。

• 主 資深大佬 : exc

  @Kinnice 程序是提供服务所在，A 用户删除了 B 用户的数据，是程序 Bug，与 Root 有何关系，如果 A 用户拥有删除 B 数据的权限，也应该是 B 用户向 A 用户授权后的结果。如果在 B 用户不知情的情况下，A 用户可以删除 B 用户的数据，那么不管怎样，都是不应该发生的。因此在这里，Root 用户是没有存在的必要的。

• 主 資深大佬 : exc

  @agagega Root 用户可以对你的数据进行任何操作，安全吗？

• 主 資深大佬 : exc

  @exc 用硬编码理解 Root 权限应该是不准确的，更应该把 Root 看做一个协议。
  在需求上，既然能明确分权限是有意义的，那么把总的权限命名为 Root 还是 Admin 还是其他，都是偏好而已。把初始化交给用户，是一种选择。默认初始化为 Root，也是一种商定好的协议。

• 資深大佬 : MozzieW

  @MozzieW 然鹅你不可否认的是，从编程角度看，Root 或类似的存在的确就是一种硬编码设计。如果说是现在的 Root 是协议的一种实现方式，那么是否有其他非硬编码的方案可以实现同样的效果呢，而非 Root 方案不可？

• 主 資深大佬 : exc

  @exc 好家伙，你离职了，公司删你 oa 账号还得你同意?

• 資深大佬 : Kinnice

  @exc 老板 /管理员删你账号，还得你同意是吗?
• 資深大佬 : Kinnice

  没有用户也就没有 root 了

• 資深大佬 : YAFEIML

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

• 資深大佬 : 12101111

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

• 資深大佬 : imn1

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

• 主 資深大佬 : exc

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

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

• 主 資深大佬 : exc

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

• 主 資深大佬 : exc

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

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

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

• 資深大佬 : luoqeng

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

• 資深大佬 : zypy333

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

• 資深大佬 : digimoon

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

• 資深大佬 : mytsing520

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

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

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

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

• 資深大佬 : PureWhiteWu

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

• 資深大佬 : FS1P7dJz

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

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

• 資深大佬 : shijingshijing

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

• 資深大佬 : chocovon

  @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 挺感兴趣的，求多说点

• 主 資深大佬 : exc

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

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

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

• 資深大佬 : xuanbg

  再看看这个

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

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

• 資深大佬 : luoqeng

  @exc 并不是，这个有限集是编译时确定的。

• 資深大佬 : PureWhiteWu

  @exc 那系统怎么知道你离职？还不是要一个 admin 用户去输入这个信息。

• 資深大佬 : NilChan

  垃圾问题，我真是垃圾，为什么要点进来。

• 資深大佬 : Whurry

  lz 很敏锐啊，一句话说到了一个盲点
  个人的感觉，注意是感觉，我并没有很清楚地 get 到我想表达的逻辑线，是：

  一个系统如果想完成自我指涉，那么自我指涉这个代词对象就是 root
  类似 this-> operation
  操作系统需要一个 get_self_user() -> operation

  如果一个系统运行完全不需要自指，那自然不会需要 root 和类似的超级权限
  但不需要自指的系统是否是完备的，我 get 不到那层逻辑

• 資深大佬 : GeruzoniAnsasu

  @xuanbg @exc

  #59 说的跟我想表达的很像

  但我存在另一个疑问（可能也是 lz 的疑问），为什么自指是必要的，或者什么样的系统是必须能自指的。不知道有没有相关解答

• 資深大佬 : GeruzoniAnsasu

  又看了一遍问题

  其实完全可以将系统设计成无初始用户，无需硬编码超级用户的样子。但这样的系统初始化时就需要你用其它手段从外部往它的数据库里写一个新用户进去，也就恰恰说明了这个系统是不完备的——这个系统不能只通过系统自己完成所有功能，比如初始化，因此它不完备。

  但这种完备性并不是这个系统的必要指标，完全能接受装机时通过另一个程序来生成初始状态，所以这个时候也的确并不需要 root

• 資深大佬 : GeruzoniAnsasu

  @GeruzoniAnsasu 归根结底，就是谁是 root 的问题。因为操作系统本身就是 root，而业务系统怕是要上溯好几层才到 root 。而且业务系统并不需要，也没有必要完备，要不然还要操作系统做什么呢。

• 資深大佬 : xuanbg

  @xuanbg 你说的没错，不过如果把时间拉长到 50 年，100 年之后呢，又会发生什么？这个操作系统是否还能自举？

• 主 資深大佬 : exc

  @PureWhiteWu 这。。。获取 Root 权限的用户依然可以自动拥有改变后的权限集呀。抱歉，我 get 不到你的点。

• 主 資深大佬 : exc

  @NilChan 当然是事件通知了，至于（离职）事件是如何产生的，有很多种可能性吧。当然现有的系统无法自动发现这些事件，需要依赖人工触发，但理论上，当数据完备时，这些事件是可以由系统自动发现并执行的。

• 主 資深大佬 : exc

  @GeruzoniAnsasu 没错，完全可以将系统设计成无初始用户，无需硬编码超级用户的样子。不过我认为，有 Root 权限的系统反而是不完备的，因为他需要依赖外部（输入）实现初始化。

• 主 資深大佬 : exc

  这样讨论似乎不会有结论。不如限定一个已有的场景，然后假设它没有 root，看这个系统会有什么问题，有什么需求，接着再想切实可行的方案去解决问题、满足需求，最后看一下终极方案，跟 root 用户这种设计有多大差异。

• 資深大佬 : oliverchen

  你永远不会知道拿着 root 权限的会是什么样的 app，不知道他们会干多可怕的事，所以把「权利放进笼子里」总是比较稳妥的，防止某些不是傻就是坏的 app 把系统搞崩。

• 資深大佬 : Mutoo

  @exc 那你说说理论上是怎样？