Macports 不也是一个思路源自 BSD 的项目么,应该和 pkgsrc 差不多吧?
不过话说没太懂,为什么要创建其他用户,以及这么做有什么坑?
Macports 不也是一个思路源自 BSD 的项目么,应该和 pkgsrc 差不多吧?
不过话说没太懂,为什么要创建其他用户,以及这么做有什么坑?
可信来源不一定要 sudo 呀,macOS 验证来源,但安装的时候不也只是 copy 一下,把软件放到 Application 文件夹下就可以了呀(甚至不移动直接运行也是可以的)。有的软件需要权限,也会弹出来输入密码的对话框。
所以你的观点和 sudo 无关的应该……而且其实更证明了用了 sudo 才让人不放心,“你都不审核,怎么敢给你用 sudo ”。
我现在理解的你的观点其实是:因为 homebrew 自己知道自己不审核,所以他不给用 sudo ,怕软件搞妖蛾子给自己带来负面影响。(其实是吐槽 homebrew 而非 sudo)对吗?
因为 GUI 运行软件前检查来源是自动发生的,终端里这个是故意关闭的。
Brew 作为社区驱动的软件,选择不用 sudo 完全可以理解,但是不代表这么做就完全没有风险
macports 是仿照 FreeBSD 的 ports 做的,和 pkgsrc 设计主要不同的地方是在系统不同地方都会创建文件,包括需要在用户的 shell profile 里加配置。pkgsrc 的 bootstrap 模式则是为了跨平台遵守在 /opt/pkg 里保持 self contained,除了 /var/db 里做缓存和 log 以外不会写入其他地方。
ARM上homebrew的目录已经移到/opt下,x86在/usr/local下。其实有个简单的场景可以参考,brew里不用sudo不会搞坏系统自带的命令,比如git,ruby什么的。要用系统的无非就是改下PATH。但是用了sudo,系统原有的环境就破坏了,很难恢复,安全性也会大打折扣。至于GUI,那只能靠自己审核,毕竟macOS也可以关闭验证,除非只用appstore里的
没太懂,brew 不会破坏系统自带的 git、ruby 等,不是因为 brew 把自己安装的程序在 PATH 里的优先级放到了系统提供的程序后面或者苹果把自己提供的程序载入到 PATH 中的优先级提高了么?
对呀,就是这样。要覆盖或者替换系统的用就必须用到sudo了。所以从我的角度讲,这样是比较安全的。
这跟 sudo 不 sudo 有什么关系,难道不是 brew 自己做了妥协么?比如,brew 的 llvm formula 没有被链接到 PATH 上,make formula 的程序名变成了 gmake。 其他的包管理器也可以采用这样的妥协方案啊,为什么能算是 brew 的专利?
用 sudo 也替换不了的,因为现在有 SIP 保护,实际上不会有包管理器会去做这种替换的,客观上也没法实现
就以我所知而言,brew 不用 sudo,代表会有很大的 unix path trojan 隐患,这个在 Unix hater Handbook 有提到过,一个作为例子的极为简单的恶作剧就是利用 PATH 变量中在前的路径覆盖在后的路径里的命令,用执行 rm -rf 的脚本替换 ls 命令,所以首先要注意的一点就是 PATH 里面不应该把不用 sudo 提升权限就能修改的路径放在前面,甚至最好避免这种路径加到 PATH 里。从结果上 brew 就是在没有把可能的风险完全告知的前提下鼓励用户做这种有风险的事,反而不止一两次我见到有人在不知道有这种木马的情况下,而且还在用没有修改权限控制保护的 git 之类常用命令优先系统自带 git 这种风险中的风险情况下说“我觉得不用 sudo 比较安全”。
下面这个链接是对这种木马的详细描述
还有,没有必要为了用没有签名的 app 全局关闭软件来源验证,网上早就广为传播的
xattr -r -d com.apple.quarantine
可以清除下载的软件带有的记号,有这个记号才会被系统提示从互联网下载的软件。这个记号的传播方式我研究过,从图形界面浏览器比如 Safari 或者 Chrome 下载就会附带上,常见的 cp,mv,乃至用图形界面解压,用系统自带的 tar 解包都会传染的。当然,如果开始就是在终端用 aria2c 或者 sftp 下载的,就不会有这个记号,自己编译的软件也没有,通过 shell pipe 复制的可执行文件也不会有。
但还是推荐运行之前还是要对软件做一些检查,哪怕下载来源没给 shasum 也可以看看打包个链接了什么动态库。
另外对于 pkg 形式的安装包,哪怕不是可疑来源的,我也会解包(用系统自带的 cpio 和 pax 命令就行)看安装脚本,方便卸载时能清除干净。如果是可疑来源的,那更要看,因为安装脚本通常是会用 sudo 执行的,而不是说这个安装包需要输入管理员密码,“哦,知道了,输入呗”
所以,可不可以认为 MacPorts 的问题是可能会卸载不干净?
这两个网站都提供了 macOS 的 pkgsrc,署名都是「MNX Cloud」,它们有什么区别?
会麻烦一些,毕竟 macports 官方网站讲了怎么卸载
是同一个网站的不同镜像,SmartOS 是 Joyent 继续基于 SunOS 的开源版本开发的,MNX Cloud 是 Joyent 对外提供面向企业的云计算服务的合作公司,被三星收购以后 Joyent 把自己对外的企业级云服务撤下了,转移给了 MNX,自己只保留给三星提供服务和对个人用户的业务,在这之后 SmartOS 的开源代码也是变成 MNX 在维护
joyent.com 的是旧的域名,分家后新启用的域名是 smartos.org
homebrew比macports还不可控,在其他地方加了文件,删的时候全看那个包做的如何(
我翻了一下 joynet 的 pkgsrc 文档,测试是说的这里么?
Bulk builds are a way to automatically build a large number of packages, generating a nice report at the end summarising the results. We use bulk builds to build our official package sets.
对,有 breakage 就就不会放二制进仓库,就要用户从 recipe 编译安装了。
这样说的话,bashrc 之类的文件也是有用户权限就能改,任意恶意软件都可以注入恶意代码,平时也很少会注意检查 bashrc 是否会被更改吧?
用 sudo 安装到系统目录,非 root 权限无法修改,的确可以起一定的保护作用,但恐怕不把 bashrc 以及用户平时的 cron job、Emacs 的配置文件等一并保护起来,也无法做到安全?
你说的 bashrc 攻击也不是只存在构想中的,最常用的几种攻击包括偷 sudo 密码,但有几点可以防范:
chflags uchg
(BSD) 或 chattr +i
(Linux) 保护用户重要配置文件不被更改,还可以设置 immutable flags 防止重要文件被误删。感谢!
能否详细讲一下输 sudo 密码之前怎么检查 shell 有无异常?我感觉这很困难。