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
Related
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.
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).
I had already installed Apache. I am using PHP for my scripting in localhost. Need to know how to run the perl script.
I have installed sudo aptitude install libapache2-mod-perl2
I have created a directory name cgi-bin in my /var/www/cgi-bin
there inside this folder i have kept my perl script perl_1.pl
The directory permissions are given.
What more i have to do to run the script????
i just type http://localhost/cgi-bin/
and i got error 403
You don't have permission to access /cgi-bin/ on this server.
please help!!
Thanks
you can't read the cgi-bin contents. You must refer directly to one of the scripts in it, in this case: http://localhost/cgi-bin/perl_1.pl
Outside of that, ensure that your cgi-bin/ directory is actually treated as such in httpd.conf.
Oh, and in case you stumble on 500 afterwards: make sure that your perl script prints a valid HTTP header. This can easily be achieved by:
use CGI qw(:standard);
print header();
And as Pwex pointed out: make sure your script has the executable bit set.
chmod 755 perl_1.pl
...should work in most cases
Additionally, for future reference it is worth mentioning mod_perl, as it is a natural next step after getting the basics of cgi + perl + apache down. Going into detail about it would be beyond the scope of this answer, but I thought I'd mention it so that you know where to go next when you've got the basics nailed down as well as seen the limitations of cgi.
How's your Apache configured ?
Did you make sure you're telling the Apache to execute CGI script in the cgi-bin directory ?
Something like:
ScriptAlias /cgi-bin/ "/var/www/website/cgi-bin/"
<Directory "/var/www/website/cgi-bin/">
Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
...
</Directory>
If you are not tied to apache or can run these scripts on different port then you can use Plack/PSGI toolchain that have solutions to run old CGI scripts as PSGI applications. See Running CGI scripts on Plack for several ways to do it.
I'm trying to run ssh, mkdir from a Perl CGI script. It's not working. But in normal Perl script, it is working fine. Can any one tell me how to run commands in a Perl CGI script?
If you're running this script via a webserver, chances are the active user (e.g. "nobody", "www", etc) may not have the necessary privileges to execute commands like mkdir and ssh. If so, that is not something that perl can fix. You can test who the active user is with something like:
print "The active user is: ", `whoami`;
It is also a security concern, to have your web user privileges set to create files and perform commands.
system() or popen() are probably what you're looking for, if you're feeling dirty I think you can use back ticks too.
Do you need to run unix commands? Perl has a built-in mkdir, and there are modules to handle SSH. Normally a CGI process is going to have limited capabilities or access to the system. The more you can do in Perl the better.
I have this perl script that I need to distribute to my coworkers who want to run the script from anywhere in the unix environment. What can I do on my part to make running this PERL script easy for them? For example, they can just have the PERL script somewhere in their directory and run just typing
./xyz.pl ttt.conf
with no path declared (like /home/abc/bin/ddd/xyz.pl ttt.conf).
The way I used to do it is add a "bin" directory in your home directory, and add it to the $PATH variable.. then you can add any script you want to use to that directory.
I am no longer familiar with the exact syntax, but something like:
in .bashrc:
$PATH = ( $PATH , $HOME/bin )
Then place the script in /home/user/bin (assuming $HOME == /home/user). When you reload the shell, it will be usable like any normal command/program.
ETA: See robert's comment below on syntax. Also, to allow your co-workers to use a script of yours, you can simply use a hard-coded path, such as /home/patrick/bin.
Put the script in /usr/local/bin (or anywhere else in $PATH). Your sysadmin may have to help you.
The technique I use is:
#!/usr/bin/env perl
This is a common way of getting the command interpreter to find Perl without either (a) moving the file, or (b) declaring the explicit path for Perl in the shebang.
It's mentioned under portability at: http://en.wikipedia.org/wiki/Shebang_(Unix)
You all are kind of right... but that perl script can sit in your path till the cows come home... and it ain't gonna run... until you set the executable bit....
:bin localadmin$ ./perlextip
-bash: ./perlextip: Permission denied
:bin localadmin$ chmod +x perlextip
:bin localadmin$ ./perlextip
Exit 0! Yeehaw.
Also, it should be noted that it need not be IN your path.... You can just call it by the full path, preceeded with a period and a slash, to execute it..
:/ localadmin$ ./ServiceData/UNIX/bin/extip
Exit 0! Yeehaw.
You can also create an alias for such a command in your ~/.bash_profile, or the such, which will let you make a system-wide shortcut of sorts, and you can even throw in a sudo, or the like, if you were so inclined... Then just call that "extip" by name anywhere, you'll be prompted for a password and, all will be well in the world.
alias extip='sudo ./ServiceData/UNIX/bin/extip'