题 Linux - 有没有办法防止/保护文件甚至被root删除?


我有一个非常重要的文件,我的工作场所中的应用程序使用,我需要确保它不会被删除,我该怎么做?


86
2017-12-02 16:02




做一个备份,这样你就可以恢复它......除此之外, chattr +i 可能会有所帮助,但也会将文件设为只读(并且可以覆盖 chattr -i),你也可以试着用SELInux等保护它。 - Sven♦
root可以创建一个甚至root无法杀死的进程吗? - Mark Gabriel
@MarkGabriel是的。叉炸弹。 :) - reirab
上帝,根,有什么区别? - Dan Neely
硬件管理员可以来取出磁盘,撕碎它,烧掉残余物并将它们喂给小猪。或者,更好的是,一些C(++)程序员可能会诱发一些鼻子恶魔。 无论什么对您很重要,请备份。两次。 - Pavel


答案:


是的,您可以将文件的属性更改为只读。

命令是:

chattr +i filename

并禁用它:

chattr -i filename

man chattr

一个带有的文件 i 属性无法修改:无法删除或重命名,无法为此文件创建链接,也无法将数据写入文件。只有超级用户或拥有该进程的进程 CAP_LINUX_IMMUTABLE 功能可以设置或清除此属性。


127
2017-12-02 16:04



对于感兴趣的,bsd等价物是 chflags schg - Andrew Domaszek
请注意,具有root访问权限的用户可以取消设置该标志,然后删除该文件。这不太可能是偶然发生的,但它不会导致故意删除。 - Grant
@Grant,如果不是 安全级别 设置得足够高。在启用网络之前,引导过程将securelevel设置为2,因此重置标志需要本地计算机访问(但这意味着在此之前引导过程中使用的文件也需要是不可变的)。 - Simon Richter
@Grant如果想要把它变为极端,你就无法阻止分区被删除或磁盘被放入熔炉或质子在10 ^ 30年内衰变...... - Hagen von Eitzen
@Itai Ganot男人我希望我4天前读过它。我考试中的一个问题= / - vfbsilva


把它刻录成CD。将CD放入CD-ROM驱动器并从那里访问它。


80
2017-12-03 15:18



+1开箱即用。并且,afaik,它在某些情况下也被使用过(黑盒cdrom驱动器,其中cd运到目的地)。无论如何,如果有人能够断开驱动器,则可能不合适。 - Alex Mazzariol
吻。我喜欢它! +1 - MonkeyZeus
我认为这是这个问题的正确答案。更改文件属性(chattr -i)无法阻止恶意操作。 - Bruno von Paris
如今,内置读卡器中的全尺寸SD卡可能是更好的解决方案 - 更低的功耗,在许多情况下更快的访问以及在非写入使用时更耐用。 - Chris H
@ jpmc26因此CD-ROM驱动器。这些是只读的。 - Thorbjørn Ravn Andersen


  1. 创建文件系统映像。
  2. 装载图像。
  3. 将文件复制到已装载的图像。
  4. 卸载映像并将其重新安装为只读。
  5. 现在你无法删除它。

例:

# dd if=/dev/zero of=readonly.img bs=1024 count=1024
# mkfs.ext2 readonly.img
# mkdir readonlyfolder
# mount readonly.img readonlyfolder/
# echo "can't delete this" > readonlyfolder/permanent.txt
# umount readonlyfolder
# mount -o ro readonly.img readonlyfolder
# cat readonlyfolder/permanent.txt 
can't delete this
# rm readonlyfolder/permanent.txt 
rm: cannot remove `readonlyfolder/permanent.txt': Read-only file system

28
2017-12-03 20:33



mount -o remount,rw readonlyfolder/ && rm readonlyfolder/permanent.txt - Kaz Wolfe
更进一步,你可以使用 squashfs 要么 cramfs 它们是压缩和只读的。它需要一个特殊的工具来构建文件系统。 - Zan Lynx


您还应该创建多个指向该文件的硬链接。这些应位于常规用户无法访问的不同位置。

这样,即使他们设法覆盖您的chattr保护,数据仍将保留,您可以轻松地将其恢复到应用程序正在查找的位置。


6
2017-12-03 05:15



硬链接不会保护文件的内容。 - 200_success
但是,它们将为DELETION提供额外的保护,这是最初的问题。 - barbecue
@barbecue如果文件在应用程序查找的名称处取消链接,则文件的内容以其他名称存在并不重要。对于查找具有预期名称的文件的任何内容,该文件仍然已被删除。 - α CVn


Linux就是所谓的 绑定贴装 选项,这是一个相当强大和有用的功能 知道

%  cd $TMP && mkdir usebindmountluke && cd usebindmountluke
%  echo usebindmountluke > preciousfile
%  sudo mount -B preciousfile preciousfile
%  sudo mount -oremount,ro preciousfile
%  echo sowhat > preciousfile
zsh: read-only file system: preciousfile
%  rm preciousfile
rm: cannot remove ‘preciousfile’: Read-only file system

- 这里做的是绑定挂载文件到自己(是的,你可以在Linux中做到这一点),然后它重新安装在R / O模式。当然,这也可以在目录中完成。


6
2017-12-06 23:40





其他人已经回答了你提出的问题。正如@Sven在评论中提到的那样,问题的一般解决方案是“如何确保我永远不会丢失文件?”是创建文件的备份。制作文件的副本并将其存储在多个位置。此外,如果文件非常重要且您的公司有使用备份服务备份重要数据的策略,您可能会考虑将此文件包含在服务中。


5
2017-12-03 07:02



好吧,当然这个文件正在定期备份,我只是希望对用户提供另一层保护,这些用户有时会使用root用户权限进行操作。


在评论中 凯文的答案,杰里提到:

好吧,当然这个文件正在定期备份,我只是希望对用户提供另一层保护,这些用户有时会使用root用户权限进行操作。 -

我会假设你无法改变这种做法,因为这是一个非常非常糟糕的主意。

有关使用只读设备的所有建议都存在同样的问题 - 它使您可以在需要时进行合法更改。对于可锁定的驱动器(例如SD卡),当您解锁它以进行更改时,会遇到突然容易受到攻击的问题。

我建议的是将另一台机器设置为NFS服务器,并将包含重要文件的目录共享给用户拥有的机器。以只读方式共享安装,以便具有您不信任的用户的计算机无法进行任何修改。当您需要合法地进行更改时,您可以连接到NFS服务器并在那里进行更改。

我们将此用于我们的Web服务器,因此对Web服务器的成功利用将无法插入或更改服务器随后将服务的任何文件,或更改配置。

请注意,这可以绕过所有与挂载点相关的方式:

  • 制作受保护目录的副本
  • 卸载目录
  • 移动副本代替mount,如果该mount没有足够的空间,则将其符号链接。

3
2017-12-07 13:04



为什么定期备份重要文件并努力保护原件免遭意外删除是“真的,非常糟糕的主意”?在OP的原始问题中,以及OP对您引用的答案的评论,很明显,关注的不是恶意活动,而是意外/无能的活动。 - Craig
@Craig:拥有很多root用户是一个坏主意,特别是如果不信任他们不会弄乱关键文件。 - Joe H.
啊......好吧当然是。 :-)但这不是OP问题的症结所在。 OP断言那里 是 具有root访问权限的用户应该受到保护,以防止意外删除文件。 - Craig
@Craig:这可能不是问题的关键,而是它 是 问题的关键(XY问题?)......但我不知道他们以root身份做什么,所以如果他们可以使用setuid和/或有限的sudo权限。而且你应该重新阅读这个问题,因为我没有看到Jerry没有提到他只是试图防止意外删除(“我需要确保它不会被删除”),他只给了一个跟进我看(引发了我的回应)。 - Joe H.
请参阅OP对此答案的回应 - Craig


在Linux上 一成不变 flag仅支持某些类型的文件系统(大多数本机类似的 ext4xfsbtrfs...)

在不受支持的文件系统上,另一个选项是以只读模式将文件绑定到自身。这必须分两步完成:

mount --bind file file
mount -o remount,bind,ro file

这必须在每次启动时完成,例如通过 /etc/fstab


3
2017-12-08 16:32



我希望有人 umount 该文件再次获得写入权限 - whoan