ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I've created few shell scripts to perform administration tasks. I also distributed those scripts to my subordinates for their use.
1) I want everybody can execute those scripts in their own (differnt) systems but cannot edit or view the codes what I've wrote in those scripts. As I've seen such kind of scripts somewhere with encrypted text inside.
2) I want to make such scripts which contains coloured menus, lines, text etc. Pls suggest me the detailed procedure to do the same.
for the second, dialog is what you need, just take a look at its manpage. For the first, this depends whether the other users of the scripts have root access to the computers, but even if they have no root access, this might get tricky -- a chmod 711 script doesn't work, because the shell cannot open the script to execute as a user then -- perhaps restricting the scripts to be root only readable and then creating sudo rules to run the scripts as a root without the password (but obviously restricted to these scripts) might help.
for the second, dialog is what you need, just take a look at its manpage. For the first, this depends whether the other users of the scripts have root access to the computers, but even if they have no root access, this might get tricky -- a chmod 711 script doesn't work, because the shell cannot open the script to execute as a user then -- perhaps restricting the scripts to be root only readable and then creating sudo rules to run the scripts as a root without the password (but obviously restricted to these scripts) might help.
Thanks for taking u'r time to read my concern and your reply.
My concern is that I'm distributing my sys adm scripts in clear text to differnt persons in my office, I want every body can execute those shell scripts to perform the tasks but when they want to edit or view those files (i.e. vi filename), either they shouldn't able to edit these scripts or view the actual contents of the scripts.
Pls suggest in details.
There is nothing funny in this man. Pls suggest some solution dear.
I think he was being gently ironic. But he makes many points. The additional questions that I might pose are:
(1) Whats so special in those scripts?
(2) Do these scripts contain code examples taken from public forums but without the credits as some of them ask?
(3) Are these scripts your property or your company's?
(4) Why wouldn't you want your subordinates to read the scripts?
As to not being able to change the scripts, I agree. It's a genuine need.
If your team is operating exclusively in superuser mode, then first change it. Next give appropriate file and directory permissions to execute the scripts. This should do.
I think he was being gently ironic. But he makes many points. The additional questions that I might pose are:
(1) Whats so special in those scripts?
(2) Do these scripts contain code examples taken from public forums but without the credits as some of them ask?
(3) Are these scripts your property or your company's?
(4) Why wouldn't you want your subordinates to read the scripts?
As to not being able to change the scripts, I agree. It's a genuine need.
If your team is operating exclusively in superuser mode, then first change it. Next give appropriate file and directory permissions to execute the scripts. This should do.
End
1) Whats so special in those scripts?
Ans: These scripts contains root previledged commands and I suspect that it might be used by other users or can be manipulate the scripts.
2) Do these scripts contain code examples taken from public forums but without the credits as some of them ask?
Ans: No, its only created by me. Its not derived or inspired by any script(s) from any forum.
(3) Are these scripts your property or your company's?
Ans : As I've mentioned earlier, these are only belongs to me purely.
(4) Why wouldn't you want your subordinates to read the scripts?
Ans: I suspect that they might change or modify those scripts and I want them as it is.
I hope its now all clear. Now pls do me the favour.
Scripts must be readable by the shell, and therefore by the user. If you encrypt them, there will always be a way around it since it has to be converted to text to interpret.
You could always write client/server programs, where the client runs on the user's machine and contacts the server to request execution of a script that the user doesn't have, then the server logs into the user's machine over ssh as root and executes it. That's a lot of work; more work than figuring out how to make the scripts safer.
ta0kira
PS You might be able to get away with doing a client/server thing with scripts and inetd (and maybe netcat.) I saw an example online somewhere, but I don't have the link anymore. You can also set up ssh to use RSA keys stored in ~ so that you don't have to put a password in the script. You'd have to set up the user's machines to accept that sort of login, though. Certainly more secure than giving out the scripts! As an extension of what I said before, anything that a user can execute can be reverse-engineered somehow, otherwise it couldn't be executed. The best thing to do is not allow the user to execute it; that way they don't have to have access to it.
1) Whats so special in those scripts?
Ans: These scripts contains root previledged commands and I suspect that it might be used by other users or can be manipulate the scripts.
Are you talking about setuid? Hopefully setuid on shell scripts is disabled on your machine.
Quote:
(4) Why wouldn't you want your subordinates to read the scripts?
Ans: I suspect that they might change or modify those scripts and I want them as it is.
Learn to use permissions.
Your question reeks of an amateur attempt to either spread malicious software or protect your source code.
I expect that since you are writing scripts for system administration, your linux exposure is of at least intermediate level and you know how to compile and install programs.
Permissions won't prevent copying and editing if the shell needs read access to execute the script.
Quote:
Originally Posted by abolishtheun
Your question reeks of an amateur attempt to either spread malicious software or protect your source code.
Why would someone with the ability to execute things as root need to spread malicious code with a script? Why not just ssh as root and cause mayhem?
ta0kira
I see this as a genuine requirement. Someone wrote a shell script which do something related to system administration. He need to give that to some one else for the purpose of execution. Now he don't want to share the 'code' (or secret, how he achieved to do that task with shell script) and thats why he want to restrict others to view or modify the script, but at the same time allow them to execute the script.
So in my view, it shouldn't be consider as either 'attempt to either spread malicious software' or 'bad scripts'.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.