问Bash保护脚本不被用户复制

EN

如果您是在类似Unix的系统上，并且可以访问C编译器，并且不介意拥有root特权(或sudo特权)的人最终可以获得脚本，那么您可以谨慎地考虑使用SUID程序来运行脚本。

在其他人无法修改的目录中，将脚本worked_hours的权限设置为500 (只为所有者读取和执行)(我假设是/home/you/bin/worked_hours)。请注意，为了真正安全起见，其他人不应该能够修改/或/home或/home/you或/home/you/bin -而且您不能阻止root修改这些目录，因此您必须信任您的root-privileged用户。

从源代码hours_worked创建程序hours_worked.c

#include <unistd.h>

int main(int argc, char **argv)
{
    argv[0] = "/home/you/bin/worked_hours";
    execv(argv[0], argv);
    return 1;
}

编译它，并放在您信任的目录中，其他人可以使用它，但不能修改它-所以您拥有的目录的755权限-我假设您使用/home/you/bin。将hours_worked上的权限设置为4511 (SUID，所有者- you可读和可执行，其他人可执行)。

现在告诉人们运行/home/you/bin/hours_worked。他们不能读取这个可执行文件；他们不能读取它运行的shell脚本。但是可执行文件可以运行shell脚本。只要您确信脚本在以自己的身份运行时具有必要的特权，您就应该没事。(除非有人利用bash将有效的UID重置为真正的UID，或者任何愚蠢的东西--或者，至少是不方便的- like。)

安全风险在哪里？我假设你可以控制你的主目录和它下的bin目录，并且你相信你的同事在你的机器上拥有超级用户的特权，不会滥用他们的特权来读取脚本，等等，你根本无法可靠地阻止拥有超级用户特权的人。通过程序中最少的代码行可以避免许多风险。使用这样的绝对路径是你所能做到的最安全的。代码将命令行参数从用户中继到脚本。

它确实假定您可以编写一个足够安全的shell脚本--这是有问题的。注意，脚本运行的所有命令都将像运行它一样运行。如果您的脚本运行一个编辑器，或者运行一个运行编辑器的程序，那么您必须假设用户将能够访问shell并使用您的权限运行任意命令。任何发送的电子邮件(很可能)都会被发送，就好像是你在发送。等。确保所有工作都按预期进行是很棘手的。如果您可以创建一个alter用户(不同的用户名和用户ID)并将程序SUID设置为该用户(并且该用户也拥有该脚本)，那么您可以避免直接牵涉其中--但这意味着您在计算机上拥有设置alter用户的root特权。您将希望确信脚本正在运行您希望它运行的程序，而不是您的用户希望它运行的程序。除其他事项外，您还需要考虑路径的设置，还需要考虑LD_LIBRARY_PATH和LD_PRELOAD或它们的等价物(尽管程序是SUID这一事实应该防止使用LD_*变量)。

这足够了吗？正如我已经明确指出的，它并不完美，因为您必须信任root-privileged用户。如果你能相信他们，这是适度有效的。这远非完美，但所有其他技术也是如此。通过拥有和运行脚本的另一个自我用户，您可以获得合理的安全性。如果需要，可以编写类似的程序来撤消SUID权限：

#include <unistd.h>
int main(int argc, char **argv)
{
    setegid(getgid());
    seteuid(getuid());
    execv(argv[1], &argv[1]);
    return 1;
}

叫它unsetsugid。使用unsetsugid在秘密脚本中运行的任何可怕命令(编辑器等)前缀

/home/you/bin/unsetsugid vim /tmp/xyz

这意味着任何运行脚本的人都将以自己的身份运行编辑器，而不需要您的特权。很棘手，但很有帮助。

我觉得这是个好主意吗？不，不是真的。为什么这么担心保密？它是开源的对立面。你永远不会知道，他们可能会在你的代码中发现一个问题。

没有真正的方法可以做到这一点。你所要求的是拷贝保护，但没有人想出一个好办法。基本上，为了执行脚本，他们的计算机必须能够读取它；如果您无法控制的东西可以读取脚本，那么您就失去了对脚本的控制。

对于shell脚本，最接近的可能是用shc加密和“编译”脚本(指令这里)。但是，任何对加密的可执行文件具有读访问权限的人都可以使用解密、恢复原始脚本以及复制/修改/执行他们想要的任何操作。