How can I lock my Perl script, list I have to do
Prevent Others from read or write Perl Script.
They should have only Permission to Executing the Perl script.
This depends on your operating system, which you haven't specified.
Typically, this is not possible.
On a UNIX based system (such as Linux or Mac OS) there are three permissions that can be given to users, groups and everyone: Read, Write, and Execute.
You can remove Write permission easily enough, but Read permission is required to allow the script to be executed.
(I assume you would experience a similar problem on Windows).
The only work around I can think of would be to rewrite the script as a webservice. Then the HTTP server would need to be able to read it, but the users themselves would not.
If the system at hand is Linux/Unix and you have administrative access then you can use sudo.
With the following line in /etc/sudoers, anyone would be able to run, as author1, any executable file in the public_bin folder:
ALL ALL = (author1) /home/author1/public_bin/*
However, take a look at man sudoers to understand implications wrt. environment and command line arguments.
755 is the *nix permission you'll need. This will give the owner full access and other read and execute.
As other has said, there is no way to make your code unreadable. However,can you obfuscate you code so only a reasonably good programmer could decode it. There are online tools, if you search "perl obfuscate" on bing you'll get some good results; these tools will mean no module is required. Or my personal favorite is the module Acme::Bleach.
Related
I have an error with perl while trying to CREATE a file called .envfile in the root dir / (only for UNIX). Permission denied, which is understood. But, is there a way to write this file? I need to do it without any modules, just with a built-in functions. I expect for using chmod, but... honestly, have no idea of how to implement it in the same thread SAFELY.
I need this file to write in it my own ENVs for my software (as it is a big project with many dirs and needs to operate with many own ENVs).
Trying simple:
my $filename = '.envfile';
open FH, '>', $filename or die $!;
print FH "some data\n";
close(FH);
Apache says: Permission denied at /var/www/cgi-bin/env.cgi line 41.
Any help appreciated!
Thanks!
If I understand the question correctly, it appears that you also control the software which will ultimately read the file you're trying to create. Is that accurate? If so, change the program to get its environment from somewhere else. Where else? Preferably a new directory, so that you can make it writable by your web server without affecting anything else. I'd probably use /etc/myprogram (because /etc is the standard place for configuration files) or /var/local/myprogram (because /var is the standard place for persistent data files). But not an existing directory which is and should remain writable solely by root.
Short of exploiting a security flaw, Perl does not allow you to sidestep filesystem security (permissions). And that is a Good Thing. If it were allowed, it would mean that anyone who finds an exploit in your Perl code could then change any file on your computer, potentially replacing it with the most malicious code ever written.
Thus, the only way that your Perl can create a file in / is if it runs as root or uses su/suid to run some other program as root. And you really, really, really do not want CGI scripts or web applications running as root because, unless you do everything absolutely perfectly in your code, and there are no exploitable bugs in perl itself, or apache, or the kernel, then, by running your web code as root, you're potentially handing root access to any random script kiddie on the internet.
If you really, truly, absolutely have no choice other than to have web-accessible code write arbitrary files to /, then the least-bad, least-insecure way to do it would be to create a very tiny helper program which takes a file name and file contents as inputs, checks to verify that the named file does not already exist (so that an attacker can't use it to overwrite, say, your kernel), and then creates the named file with the provided contents. Aside from maybe a little additional sanity/security checking, it should do absolutely nothing else because the more complex this helper program is, the more likely it is to contain exploitable flaws. Then have the web code use suid to run the helper program, with suid configured to allow the web user (and only the web user) to run the helper program (and only the helper program) with no password.
But don't do that unless you really, truly, absolutely have no other option. It is not the best way to do it, it is the least bad way. Which means it's still a bad idea.
Create the file 'by hand' and set it's owner to the owner of the apache process, e.g.:
sudo touch /.envfile
sudo chown www-data:www-data /.envfile
sudo chmod u+rw /.envfile
You're executing your Perl program as a user without sufficient privilege. Run the Perl program using a user with sufficient privilege (e.g. using sudo or su).
Quite recently, I wrote a few scripts in Perl for a cPanel plugin in which, though most of the code was in Perl, there was quite a lot of system() commands as well which I used to execute shell commands directly.
I am pretty sure that there are Perl modules that I could have used instead. Keeping in mind the time crunch, I thought using the system command was easier (to complete the project in time). In retrospective, I think that was a bad programming practice.
My question is, is there any tradeoff, memory-wise or otherwise when using Perl's modules and using system() commands. For example, what would be the difference in using:
my $directory = "temp";
mkdir $directory;
and
system ("mkdir temp");
Also, if I am to use Perl modules, wouldn't that involve installing a whole lot of modules in the beginning?
The most obvious economy is that, in the first case, your Perl process is creating the directory, while in the second, Perl is starting a new process that runs a command shell which parses the command line and runs the shell mkdir command to create the directory, and then the child process is deleted. You would be creating and deleting a process and running the shell for every call to system: there is no caching of processes or similar economy.
The second thing that comes to mind is that, if your original mkdir fails, it is simple to handle the error in Perl, whereas shelling out to run a mkdir command puts your program at a distance from the error, and it is far more awkward to handle the many different problems that may arise.
There is also the question of maintainability and portability, which will affect you even if you aren't expecting to run your program on more than one machine. Once you abandon control to a system command you have no control over what happens. I could have written a mkdir that will delete your home directory or, less disastrously, your program may find itself on a system where mkdir doesn't exist, or does something slightly different.
In the particular case of mkdir, this is a built-in Perl operator and is part of every Perl installation. There are also many core libraries that require you to put use Module in your program, but are already installed and need no further action.
I am sure others will come up with more reasons to prefer a Perl operator or module over a shell command. In general you should prefer to keep everything you can within the language. There are only a few cases where you have to run a third-party program, and they usually involve custom software that allows you act on proprietary data formats.
I am very new for perl and we had very emergency requirment. I need to convert the bat file code into Perl script code. I am confused, how we add credentials in Perl.
In bat file: I have the above sample credentials
How can I change the above credentials in Perl. How to write the above credentials in Perl script.Help is very much appropriated
To execute an external command, you probably want to use the system built-in. It will not capture the output, however:
system "program", "-argument", "value", "-argument2", ...;
before using it, you should read the whole documentation and also look into exec, qx{} and open, for different nuances.
If your requirements are more complex, you should look into the IPC family of modules on CPAN.
I am using a Windows System Command Prompt to call on a Perl Script. At one point and time, the Perl Script calls on svn+ssh to update a repo. The repository that is called asks the for user input - specifically a password.
I am trying to automate the execution of the Perl Script, but it continually gets hung up on the call to svn. I have tried many forms of input redirection (specifically < with an external file, | with cat, and the windows power shell use of the # symbol to specify a multi-lined string). Is there a way to input a password for this Perl script?
For purposes of this problem, I do not have access to the Perl Script and I will need to implement a work around.
You don't mention the svn+ssh implementation the script uses, but my guess is that the problem is this:
SSH clients tend to ask for passwords directly from the terminal. Password prompts often don't read from stdin, so you can't redirect input. For example, the OpenSSH client does it that way. It is designed that way to prevent users from doing insecure things - like storing passwords in files, environment variables or shell variables.
The common recommandation in this situation is to use public key authentication.
Without knowing your script, it will not be possible to come up with a workaround I think.
I wrote a very simple perl script, and now I want to make it executable from everywhere.
I know I could just drop it into /bin/, rename it from 'mytest.pl' -> 'mytest', and chmod +x, but is this standard practice? I noticed nothing in /bin/ is a perl script.
Also, I want it to be able to log to /var/logs/mytest/*
Are there any security issues I should be aware of?
It is preferable to put user-made scripts in /usr/local/bin , but it's your call whether it's worth worrying about this. As far as logging to /var/logs/mytest/*, you can try to make the script suid (this is sometimes not allowed for security) with a user that can write to the dir, or just make /var/logs/mytest world-writable.
Instead of worrying about log file permissions issues, why not log to the system logger? That's what it's there for. See Sys::Syslog