3

如果在应用程序运行时它使用的共享库之一被写入或截断，则应用程序将崩溃。移动文件或使用 'rm' 批量删除文件不会导致崩溃，因为操作系统（在这种情况下是 Solaris，但我认为这在 Linux 和其他 *nix 上也是如此）足够聪明，不会删除与该文件，而任何进程打开它。

我有一个执行共享库安装的 shell 脚本。有时，它可用于重新安装已安装的共享库版本，而无需先卸载。因为应用程序可能正在使用已经安装的共享库，所以脚本足够聪明以 rm 文件或将它们移开（例如，当我们知道没有应用程序时 cron 可能会清空的“已删除”文件夹），这一点很重要将运行），然后再安装新的，这样它们就不会被覆盖或截断。

不幸的是，最近一个应用程序在安装后就崩溃了。巧合？很难说。这里真正的解决方案是切换到比旧的巨大 shell 脚本更健壮的安装方法，但是在切换之前有一些额外的保护会很好。有没有办法包装一个 shell 脚本来保护它不被覆盖或截断文件（最好是大声失败），但仍然允许它们被移动或 rm'd？

标准 UNIX 文件权限无法解决问题，因为您无法区分移动/删除和覆盖/截断。别名可以工作，但我不确定需要别名的所有命令。我想像 truss/strace 之类的东西，除了在每个操作之前它检查过滤器是否实际执行它。我不需要一个完美的解决方案，即使是针对故意的恶意脚本也能起作用。

4

3 回答 3

2

您可以通过以下方式防止脚本通过 I/O 重定向覆盖

set noclobber

防止覆盖cp等更难。我的倾向是重置PATH脚本以运行PATH仅包含一个条目的“祝福”目录，您可以在其中放置您知道是安全的命令。例如，这可能意味着您的版本cp总是被安排为使用该--remove-destination选项（可能是 GNU 主义）。在任何情况下，您都安排脚本只执行来自祝福目录的命令。然后，您可以单独审查每个此类命令。

如果您可以阻止脚本通过绝对路径名执行命令，那就太好了，但我不知道该怎么做。如果您在常规目录中进行安装，chroot除非您进行大量环回安装以使这些目录可见，否则监狱可能无济于事。如果您要安装的目录包含危险命令，我看不出您如何完全保护自己免受它们的侵害。

顺便说一句，我尝试并未install(1)能了解是否在安装之前删除了目标。学习会很有趣。

于 2010-03-06T22:25:35.123 回答
1

我认为是 Bash 脚本？剧本很长吗？如果没有，您可以手动执行此操作：

if [ ! -f /tmp/foo.txt ] #If file does not exist
then
    ...code
fi

但是我认为您正在寻求一种将其包装在脚本周围的方法。您当然可以使用 strace 监视文件写入，但 AFAIK 它没有中断它们的功能，除非您使用规则等设置某种入侵检测系统。

但老实说，除非它是一个巨大的脚本，否则这可能比它的价值更麻烦

于 2010-03-06T20:50:28.783 回答
0

编写您自己的 safe_install() 函数并确保它们是唯一使用的方法。如果您确实需要确定，请运行两个进程。一个将有权进行更改，另一个将提前放弃所有特权并告诉另一个脚本执行实际的磁盘工作。

于 2010-03-07T01:30:45.663 回答