blocks|key|2625584|text|没有真正的方法可以做到这一点。你所要求的是拷贝保护，但没有人想出一个好办法。基本上，为了执行脚本，他们的计算机必须能够读取它；如果您无法控制的东西可以读取脚本，那么您就失去了对脚本的控制。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2625585|对于shell脚本，最接近的可能是用shc加密和“编译”脚本(指令这里)。但是，任何对加密的可执行文件具有读访问权限的人都可以使用解密、恢复原始脚本以及复制/修改/执行他们想要的任何操作。|offset|length|2625586|entityMap|0|LINK|mutability|MUTABLE|url|http://www.datsi.fi.upm.es/~frosal/|1|http://www.thegeekstuff.com/2012/05/encrypt-bash-shell-script/|2|http://www.l0d.org/Decrypt_an_shc_crypted_file.html^0|0|I|3|0|X|2|1|1T|2|2|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]|$D|W|E|X|1|Y]|$D|Z|E|10|1|11]]|A|$]]|$1|F|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]|N|$5|I|J|K|A|$L|O]]|P|$5|I|J|K|A|$L|Q]]]]

There's no real way to do this. What you're asking for is copy protection, which nobody has ever figured out a good way to do. Basically, in order to execute the script, their computer must be able to read it; if something you don't have control over can read the script, you have lost control of the script.

For a shell script, the probably the closest you could come would be to encrypt and "compile" the script with <a href="http://www.datsi.fi.upm.es/~frosal/" rel="nofollow">shc</a> (instructions <a href="http://www.thegeekstuff.com/2012/05/encrypt-bash-shell-script/" rel="nofollow">here</a>). However, anyone with read access to the encrypted executable can <a href="http://www.l0d.org/Decrypt_an_shc_crypted_file.html" rel="nofollow">decrypt it</a>, recover the original script, and copy/modify/do whatever they want with it.

blocks|key|2625641|text|如果您是在类似Unix的系统上，并且可以访问C编译器，并且不介意拥有root特权(或sudo特权)的人最终可以获得脚本，那么您可以谨慎地考虑使用SUID程序来运行脚本。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2625642|在其他人无法修改的目录中，将脚本worked_hours的权限设置为500+(只为所有者读取和执行)(我假设是/home/you/bin/worked_hours)。请注意，为了真正安全起见，其他人不应该能够修改/或/home或/home/you或/home/you/bin+-而且您不能阻止root修改这些目录，因此您必须信任您的root-privileged用户。|2625643|从源代码hours_worked创建程序hours_worked.c|2625644|#include+<unistd.h>

int+main(int+argc,+char+**argv)
{
++++argv[0]+=+"/home/you/bin/worked_hours";
++++execv(argv[0],+argv);
++++return+1;
}|code-block|syntax|javascript|2625645|编译它，并放在您信任的目录中，其他人可以使用它，但不能修改它-所以您拥有的目录的755权限-我假设您使用/home/you/bin。将hours_worked上的权限设置为4511+(SUID，所有者- you可读和可执行，其他人可执行)。|2625646|现在告诉人们运行/home/you/bin/hours_worked。他们不能读取这个可执行文件；他们不能读取它运行的shell脚本。但是可执行文件可以运行shell脚本。只要您确信脚本在以自己的身份运行时具有必要的特权，您就应该没事。(除非有人利用bash将有效的UID重置为真正的UID，或者任何愚蠢的东西--或者，至少是不方便的- like。)|2625647|安全风险在哪里？我假设你可以控制你的主目录和它下的bin目录，并且你相信你的同事在你的机器上拥有超级用户的特权，不会滥用他们的特权来读取脚本，等等，你根本无法可靠地阻止拥有超级用户特权的人。通过程序中最少的代码行可以避免许多风险。使用这样的绝对路径是你所能做到的最安全的。代码将命令行参数从用户中继到脚本。|2625648|它确实假定您可以编写一个足够安全的shell脚本--这是有问题的。注意，脚本运行的所有命令都将像运行它一样运行。如果您的脚本运行一个编辑器，或者运行一个运行编辑器的程序，那么您必须假设用户将能够访问shell并使用您的权限运行任意命令。任何发送的电子邮件(很可能)都会被发送，就好像是你在发送。等。确保所有工作都按预期进行是很棘手的。如果您可以创建一个alter用户(不同的用户名和用户ID)并将程序SUID设置为该用户(并且该用户也拥有该脚本)，那么您可以避免直接牵涉其中--但这意味着您在计算机上拥有设置alter用户的root特权。您将希望确信脚本正在运行您希望它运行的程序，而不是您的用户希望它运行的程序。除其他事项外，您还需要考虑路径的设置，还需要考虑LD_LIBRARY_PATH和LD_PRELOAD或它们的等价物(尽管程序是SUID这一事实应该防止使用LD_*变量)。|2625649|这足够了吗？正如我已经明确指出的，它并不完美，因为您必须信任root-privileged用户。如果你能相信他们，这是适度有效的。这远非完美，但所有其他技术也是如此。通过拥有和运行脚本的另一个自我用户，您可以获得合理的安全性。如果需要，可以编写类似的程序来撤消SUID权限：|2625650|#include+<unistd.h>
int+main(int+argc,+char+**argv)
{
++++setegid(getgid());
++++seteuid(getuid());
++++execv(argv[1],+&argv[1]);
++++return+1;
}|2625651|叫它unsetsugid。使用unsetsugid在秘密脚本中运行的任何可怕命令(编辑器等)前缀|2625652|/home/you/bin/unsetsugid+vim+/tmp/xyz|2625653|这意味着任何运行脚本的人都将以自己的身份运行编辑器，而不需要您的特权。很棘手，但很有帮助。|2625654|我觉得这是个好主意吗？不，不是真的。为什么这么担心保密？它是开源的对立面。你永远不会知道，他们可能会在你的代码中发现一个问题。|2625655|entityMap^0|Y|4|16|4|0|G|C|1J|Q|2Y|1|30|5|36|9|3G|D|42|4|4M|4|0|4|C|K|E|0|0|1G|D|1V|C|2U|3|0|8|Q|3H|4|0|P|3|0|7A|4|97|F|9N|A|AO|4|0|U|4|0|0|2|A|F|A|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1A|8|@$9|1B|A|1C|B|C]|$9|1D|A|1E|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1F|8|@$9|1G|A|1H|B|C]|$9|1I|A|1J|B|C]|$9|1K|A|1L|B|C]|$9|1M|A|1N|B|C]|$9|1O|A|1P|B|C]|$9|1Q|A|1R|B|C]|$9|1S|A|1T|B|C]|$9|1U|A|1V|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1W|8|@$9|1X|A|1Y|B|C]|$9|1Z|A|20|B|C]]|D|@]|E|$]]|$1|J|3|K|5|L|7|21|8|@]|D|@]|E|$M|N]]|$1|O|3|P|5|6|7|22|8|@$9|23|A|24|B|C]|$9|25|A|26|B|C]|$9|27|A|28|B|C]]|D|@]|E|$]]|$1|Q|3|R|5|6|7|29|8|@$9|2A|A|2B|B|C]|$9|2C|A|2D|B|C]]|D|@]|E|$]]|$1|S|3|T|5|6|7|2E|8|@$9|2F|A|2G|B|C]]|D|@]|E|$]]|$1|U|3|V|5|6|7|2H|8|@$9|2I|A|2J|B|C]|$9|2K|A|2L|B|C]|$9|2M|A|2N|B|C]|$9|2O|A|2P|B|C]]|D|@]|E|$]]|$1|W|3|X|5|6|7|2Q|8|@$9|2R|A|2S|B|C]]|D|@]|E|$]]|$1|Y|3|Z|5|L|7|2T|8|@]|D|@]|E|$M|N]]|$1|10|3|11|5|6|7|2U|8|@$9|2V|A|2W|B|C]|$9|2X|A|2Y|B|C]]|D|@]|E|$]]|$1|12|3|13|5|L|7|2Z|8|@]|D|@]|E|$M|N]]|$1|14|3|15|5|6|7|30|8|@]|D|@]|E|$]]|$1|16|3|17|5|6|7|31|8|@]|D|@]|E|$]]|$1|18|3|-4|5|6|7|32|8|@]|D|@]|E|$]]]|19|$]]

If you're on a Unix-like system and have access to a C compiler, and don't mind that people with <code>root</code> privileges (or <code>sudo</code> privileges) can get at the script after all, then you could consider, cautiously, using a SUID program to run the script.

Set the permissions on the script, <code>worked_hours</code> to 500 (read and execute for owner only) in a directory which other people cannot modify (I'll assume <code>/home/you/bin/worked_hours</code>). Note that to be truly safe, other people should not be able to modify <code>/</code> or <code>/home</code> or <code>/home/you</code> or <code>/home/you/bin</code> — and you can't stop <code>root</code> from modifying those directories, so you have to trust your <code>root</code>-privileged users.

Create a program <code>hours_worked</code> from source code <code>hours_worked.c</code>:

<pre><code>#include &lt;unistd.h&gt;

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

Compile it, and place in a directory you trust where other people can use it but not modify it — so 755 permission on a directory you own — I'll assume you use <code>/home/you/bin</code>. Set the permissions on <code>hours_worked</code> to 4511 (SUID, readable and executable by the owner — <code>you</code> — and executable by others).

Now tell people to run <code>/home/you/bin/hours_worked</code>. They can't read this executable; they can't read the shell script it runs. But the executable can run the shell script. As long as you're confident that the script has the necessary privileges when run as yourself, you should be fine. (Unless someone has screwed around with <code>bash</code> so that it resets the effective UID to be the real UID, or anything silly — or, at minimum, inconvenient — like that.)

Where are the security risks? I'm assuming that you can control your home directory and the <code>bin</code> directory under it and that you trust your colleagues with super-user privileges on your machine not to abuse their privileges to read the script, etc. You simply can't reliably stop people with super-user privileges. Many risks are avoided by the minimal number of lines of code in the program. Using an absolute path like that is about as safe as you can make it. The code does relay command line arguments from the user to the script.

It does assume you can write a sufficiently secure shell script — which is problematic. Note that all commands run by the script will be run as if you were running it. If your script runs an editor, or runs a program that runs an editor, you have to assume that the users will be able to get to a shell and run arbitrary commands with your privileges. Any emails sent will (most likely) be sent as if it was you doing the sending. Etc. Making sure that all works as intended is tricky. If you can create an alter ego user (different user name and user ID) and make the program SUID to that user (and that user owns the script too), then you can avoid being directly implicated — but it implies you have <code>root</code> privileges on the machine to set up the alter ego user. You will want to be confident that the script is running the programs you want it to run and not the programs your users want it to run. Amongst other things, you'll need to consider the setting of PATH, and also worry about <code>LD_LIBRARY_PATH</code> and <code>LD_PRELOAD</code> or their equivalents (though the fact that the program is SUID should prevent the <code>LD_*</code> variables being used).

Is this sufficient? As I've clearly stated, it is not perfect because you have to trust <code>root</code>-privileged users. If you can trust them, it is moderately effective. It is far from perfect, but then so are all the other techniques. With an alter ego user owning and running the script, you can get reasonable security. If you need to, you can write a similar program to undo SUID permissions:

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

Call it <code>unsetsugid</code>. Prefix any scary commands (editors, etc) run in your secret script with <code>unsetsugid</code>:

<pre><code>/home/you/bin/unsetsugid vim /tmp/xyz
</code></pre>

This means that anyone who runs the script will run the editor as themselves without your privileges. Tricky, but helpful.

Do I think this is a good idea? No, not really. Why are so worried about the secrecy? It is the antithesis of open source. You never know, they might spot a problem in your code.

I recently wrote a bash script that calculates the number of worked hours in a month given the arrival/departure times for each day. Some coworkers are interested to purchase it. But I just want them to be able to execute the file, and not be able to change the code, or send it to others to use for free. I know I can use the chmod command to set permissions, but so can they. Is there any other command or program that I could use to protect the script from getting copied or attached in an email?

also let me know if you think this is not related to "stackoverflow.com"

EDIT:
OK here is what I want to know specifically:
Is there anyway that you can set a bash script to rx permissions so users can only run the script, without them being able to change the permissions? My problem is that the users can change the permissions using the chmod command as well. All users use Windows, so the script will be run using Cygwin. I can write a C/C++ or a Java program that does the same thing, but I want to know how to do this for a bash script bash, cause I'm learning bash. I rather not implement password protected script as long as possible.

I'm not too worried if the users can change this script, but I'm REALLY interested to know if there is a not too complicated way to do this for my future references, since I'm planning to do a lot of bash scripts.

Please leave a comment if the question is still to broad, or if I still need to edit the question.

Bash protect a script from getting copied by users

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我最近写了一个bash脚本，根据每天的到达/离开时间，计算一个月的工作时数。有些同事有兴趣购买它。但我只希望他们能够执行文件，而不能更改代码，也不能将其发送给其他人免费使用。我知道我可以使用chmod命令来设置权限，但它们也可以。还有其他命令或程序可以用来保护脚本不被复制或附加在电子邮件中吗？如果你认为这与"stack...

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

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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