Installing Perl modules on a UNIX virtual server when you don’t have root or administrator privledges.

Before you begin: In order to install modules, you have to have SSH or Telnet access to the server. If you don’t have this access (or you don’t know what SSH/Telnet means) then you’ll probably have to get your system administrator to install modules for you.

I recently wanted to install the DBD::CSV module on my virtual host server (UNIX FreeBSD) and found that it was more challenging than I would have liked. I’m not positive I have the best approach, but it did work for me in the end. Following are the steps that I had to take to get the module and all those on which it depends installed. The primary problem is that on the virtual server, I don’t have root/administrator privledges. So, I have to install Perl modules in an alternate directory. The scripts have to be altered to point to that directory as well.

To install my beloved DBD::CSV, I notice that I also have to have all of the following modules installed and working:

DBI
File::Spec
Text::CSV_XS
SQL::Statement

So, we will install those first, then finally install DBD::CSV.

First, I set up MCPAN. This is a Perl utility that automatically downloads, unpacks, compiles and installs Perl modules. Since I don’t have root, I was only able to utilize MCPAN for the downloading and upacking part. I still had to compile and install the modules manually. If you don’t have access to, or don’t want to bother with MCPAN, then you can just download the modules directly from http://www.cpan.org and unpack them yourself.

To run MCPAN, you enter something like this (this will start the process of installing DBI, the first required module):

perl -MCPAN -e 'install DBI'

The first time I ran this utility, I was automatically taken through an installation process. A directory ~/.cpan was created in my home directory and I was prompted with several questions. I simply used all the defaults. There was only one question that I had trouble with, which was something like “What is your favorite CPAN mirror.” This seemed to be asking where to look for downloadable modules. I wish I remembered what I put, but it took me several tries to find one that worked. I finally wound up entering a server in Japan, which I’m sure is not good. But it worked. You might check for possible server locations here: http://www.perl.com/CPAN

Anyway, after running that the first time, the DBI module installation files were saved in ~/.cpan/build/DBI-1.14. (in case you don’t know ~/ usually means your home directory), however the installation failed because it tried to write some stuff to the main Perl installation location and, again, I don’t have permission to write there. however, when you are manually installing modules, I do know that you can specify an alternate directory. So, I went into the ~/.cpan/build/DBI-1.14 directory and manually installed it like so:

cd ~/.cpan/build/DBI-1.14
perl Makefile.PL INSTALLDIRS=site INSTALLSITELIB=/usr/www/users/myaccount/cgi-bin/lib
make
make test
make install

When I installed it, I see that I got a few errors and such. Upon closer inspection, it seems that the POD documentation and other stuff is still trying to go in the main Perl library location. I ignore these errors, since it doesn’t seem to effect anything but the documentation. Obviously, you want to replace /usr/www/users/myaccount/cgi-bin/lib with the location on your server where you want to save the modules.

Anyway, now I try the File::Spec module:

perl -MCPAN -e 'install File::Spec'
cd ~/.cpan/build/File-Spec-0.82
perl Makefile.PL INSTALLDIRS=site INSTALLSITELIB=/usr/www/users/myaccount/cgi-bin/lib
make
make test
make install

That one was easy. I still got errors, but I just ignore them. Now I try Text::CSV_XS:

perl -MCPAN -e 'install Text::CSV_XS'
cd ~/.cpan/build/Text-CSV_XS-0.21
perl Makefile.PL INSTALLDIRS=site INSTALLSITELIB=/usr/www/users/myaccount/cgi-bin/lib
make
make test
make install

Same old thing. More errors. Moving along to SQL::Statement…

perl -MCPAN -e 'install SQL::Statement'
cd ~/.cpan/build/SQL-Statement-0.1016
perl Makefile.PL INSTALLDIRS=site INSTALLSITELIB=/usr/www/users/myaccount/cgi-bin/lib
make
make test
make install

Another one bites the dust. The final one, DBD::CSV is more tricky because when I tried the same thing, it doesn’t work. I can’t do the Makefile.PL part of it because it says I am missing some required modules. What is happening is that the installer is looking in the standard Perl path - however we have been installing all of our goodies to an alternate location and Perl doesn’t know about it. My solution is that I simply comment out the lines in Makefile.PL where it checks for all the required modules! That’s a crappy way to do it, but it works.

perl -MCPAN -e 'install DBD::CSV'
cd ~/.cpan/build/DBD-CSV-0.1024

Now I edit Makefile.PL and comment out these lines (about 20 lines down from the top or so)

# $ok &&= CheckModule('DBI', '1.00');
# $ok &&= CheckModule('Text::CSV_XS', '0.16');
# $ok &&= CheckModule('SQL::Statement', '0.1011');

That’s it. the rest is the same.

perl Makefile.PL INSTALLDIRS=site INSTALLSITELIB=/usr/www/users/myaccount/cgi-bin/lib
make
make test
make install

All done at last! I tried my script and it worked just fine. One adjustment that you might have to make to your script is to add the location of your libraries to your script. You do this by putting the location in a BEGIN clause in your script like so:

BEGIN {
unshift(@INC,"/usr/www/users/myaccount/cgi-bin/lib");
}

Put this at the top of your script before any other subroutines or anything. That tells your script to look there when loading modules. Since you use the “unshift” function, your path is added to the front of the list. If you would rather your script look in the regular places first, and look in your custom path last, then you can use “push” instead of “unshift.”

One final thing. I went into ~/.cpan/build/ and deleted all the files and folders. I get charged for disk space overusage, so no use keeping all those installation files, right?

Share This

vi is a text editor that is installed pretty much on all UNIX systems. favored by old-school geeks, vi can be somewhat complex to use. However the basics are pretty easy. Most of us only need the basics to go into a config file and change a setting.

Starting vi:

vi [filename] - opens a file using the vi text editor. if this is an existing file, it will edit. otherwise, it will create a new, blank file.

Panic Button!

:q! then hit the enter key= exit without saving. useful when things go out of control!

Switching “modes”

the first confusing part is that vi has different “modes” while you are editing a file. They are known as “command” mode and “input” mode.

Esc - takes you back to command mode.

i, a, A, r or R - (while in command mode) goes into insert mode.

Moving Around:

Moving around the file is done in command mode. if your terminal is set up correctly, the up,down,left,right arrows will nmove the cursor around.

if your terminal is not set up correctly, then you have to use j=down, k=up, h=left, l=right.

/[search term] then hit enter = the slash followed by a search term will move the cursor to the next occurance of that term. handy for locating configuration settings.

?[search term] then hit enter = same as search, but searches backwards.

ctrl+shift+R = screen refresh. especially when scrolling, vi has a tendency not to redraw the whole screen correctly. use this to refresh the screen.

Deleting

Deleting is again done from command mode. This is probably the most confusing part of vi for me personally. because input mode allows you to enter new characters. but to delete existing ones, you must exit back to command mode and delete them.

x = delete current character
dd = delete entire current line
u = undo last edit

Inserting / Editing

i = enter insert mode starting before current char
a = goto insert mode starting after current character
A = goto insert mode at end of current line.
r = overwrites next character typed then exits back to command mode
R = goto insert mode, but overwriting instead of inserting

when you enter insert mode, you just start typing as you would with any editor. it’s pretty simple. When you’re done typing, or you want to move the cursor to make a correction, hit Esc to return to command mode.

Exiting vi with and without saving

(This is all done in command mode)

:q! then hit enter = exit without saving

shift+ZZ then hit enter = save and exit.

Getting Help

:viusage = shows vi commands
:h = general help screen

Share This

The Problem:

I find a lot of surprising security problems as I work on client’s sites. Even large, reputable companies often have gross security issues. I know more than anyone how difficult it can be to get a cgi script installed and working. It’s tempting to walk away without double-checking the security. One of the most common things that I see is poor security of the cgi-bin. Depending on the setup of your server, someone can take total control of your account easily through a poorly secured cgi-bin.

The particular problem i’m writing about involves writable files/directories within your cgi-bin, or scripts that make calls to external programs (like sendmail). These are both very common types of scripts that you would find in just about any cgi-bin.

The writable file issue is that most cgi scripts rely on a datafile to store their information. In some cases, they need an entire writable directory to store data (file uploads, etc). The tricky part is that you have to allow the script write access to the file/directory. If your server is running as “nobody” then you need to allow world write access to the file. This is dangerous because other users on the server also have the ability to run under the “nobody” user - which means they can also write to those files. Some servers are configured so that scripts execute under your own userid. Otherwise sensible people are fooled into thinking that they are protected by this. Although it does protect you from the “nobody” exploits, it actually make the potential damage much worse if you have poor security settings.

The issue with scripts that make calls to external programs (like Formail for sending email via sendmail, etc) is that if they are not coded properly, someone can input malicious text that causes an arbitrary shell command to run in addition to the sendmail command. This command will run under whatever userid that the original script has.

One dangerous situation is a script that allows file uploads and it’s writable directory is in the cgi-bin. Any script like this should have serious security checks in place to prevent malicious files from being uploaded. If the script doesn’t check file types as they upload, any anonymous user can upload a script or executable file right to your cgi-bin.

Another situation is on a virtual host where you share your account with lots of other users. This exploit is only available to people who have an account on your machine, however it is no less a problem. All users on your server can install cgi scripts in their account which run under the “nobody” permissions. If they install a simple command processing script, they can manipulate any file in your account that allows world write access.

So, take a look at your cgi-bin and look for any writable files or directories. Imagine what would happen if someone could edit or add any file there in your cgi-bin. A writable directory is particularly bad because the other person on your server can actually write a new script file there and then browse to the url to execute it.

Normally if someone can totally compromise your site in this way, they are limited to running as the user “nobody.” However, there is still quite a bit of damage that can be done. Formmail scripts can be installed to send spam. Scripts to snoop into your datafiles can be installed. Large files can be uploaded and shared (using your bandwith). I once had a client who incurred a $10,000 bandwidth bill after their server was compromised by hackers sharing video game software. Nothing more than “nobody” access is needed to do this.

If cgi-wrap is enabled, the situation is compounded because the scripts in your cgi-bin can be executed through cgi-wrap to run under your own userid. At that point, they own your account.

How To Secure cgi-bin:

There’s a few simple things that can help lock down your cgi-bin.

1. Never, ever have a file with both world-execute and world-write permissions. This can be overwritten with any arbritrary code by any user on your server. Once they overwrite, they can execute it through the browser. Scripts themselves should never require write permission. Read/Execute is fine (chmod 505 is nice and secure).

2. If possible, never have any writable directories or files in the cgi-bin. Not even writable by your own user id. there is no reason that a file needs to be writable within the cgi-bin. Depending on what scripts you have installed, this can be challenging. The solution is to move all datafiles to an area that is not accessible through the web browser. If this is not possible, see # 3

3. If you must have writable files or folders in the cgi-bin because of the functionality of a script, keep them in a subdirectory and put an .htaccess file in there that has the contents “deny from all” in it. Your scripts can still read/write files there, but nothing can be executed through the browser. if you are not able to put them in a separate directory, you can deny access to specific files using .htaccess.

4. Never give any permissions to the “group.” In UNIX you have three permissions to grant - owner, group, world. for example, chmod 644 grants 6 (rw) to owner, 4 (r) to group and 4 (r) to the world. The group is almost always other accounts on your server. You generally do not know these other users and there is no reason to give them any permissions for any file in your account. The middle value should always be zero. for example: chmod 604 gives the group 0 (no access) which is fine.

5. be very careful when cgi-wrap is enabled or your cgi-bin executes using your own account’s userid. in this case you have to make sure that nothing can be written arbitrarily into your cgi-bin even using your own account permissions. Keep in mind that you do not need permission to write to a script. You can remove the write permission even for yourself. If you need to change it later, you first change the permission to allow write, then change it back. It doesn’t need to sit there with write permissions. You have to be very cautious about what scripts are installed, because any script with an exploit can be dangerous. if someone can write or upload to your cgi-bin, they can create their own script and run it under you userid. If you use cgi-wrap, there is no reason for the group or the world to have any permissions on your files. so, you should change permissions something like this: chmod 400 (only you have read permission). scripts can be chmod 500. writable datafiles can be chmod 600, but should not be stored in a public area. remember that if someone can run arbitrary code as your userid, they own your account!

6. Try to break into your own account. Go through your scripts and try to upload a file that shouldn’t be allowed. Look at scripst that send email and see if you can enter data in such a way that code gets executed.

Summary:

The moral of the story is to be cautious with your cgi-bin. Especially look for writable files and directories. Never trust other users on your server. It may not seem important to take security seriously for your homepage with a bulletin board and formmail script. But there are malicious people out there always scanning for easy targets. Your data can be compromised or your bandwidth stolen - leaving you with the bill. A little bit of extra time can save you a lot of grief later.

Share This