/tmp folder too small

[alan02532]

Anyone having weird file upload or extraction problems should consider whether 1and1 has left you with a tiny tiny /tmp folder that can't hold ****.

I have an OSCommerce site that just can't change the sessions dirtectory to anything other than /tmp, which is always filling up, so the session can't be recreated

I don't know why the directory has to be /tmp. I can change it but it won't write to the new directory. When I change it back to /tmp it says it is full.

So I did a link from /tmp into home/tmp and transferred all the files there.

Now it works fine decrompressing files and sessions

Took some doing to recreate the pipes in the /home/tmp directory , but somehow got it done.

Maybe this is why the guy couldn't upload files.

[MyronNet]

Odd, but my /tmp folder has an assortment of files all of which are 0k.... and I've been having hda1 100% full issues. :confused:

[eWebtricity]

Whats your partition table look like ? Is it the old style where the / partition contained everything or more like the recent update 1and1 just did where the client directory is now under /var

[AntiochWebHost]

I believe that you can reconfigure where PHP dumps temporary files to in /etc/php.ini -- and if you're using osCommerce, I believe that the temporary file directory can also be defined within the domain's webspace by configuring osCommerce via their /admin/ area.

[eWebtricity]

or make a symlink in the /tmp partition to another partition that has more space

[AntiochWebHost]

... or there's that excellent suggestion too! =) Good one, eWebtricity!

[johnwong]

I used to create a loop back file for the /tmp directory Not only to have a bigger /tmp directory, I can have some limited protection from script kiddies. Those script kiddies like to use some PHP application weakness (like older version of phpBB, zeroboard) to instruct php to download source code, compile it and execute the binary. The binary may be something to DoS or sending spam emails .... Therefore, I used to send up a separate /tmp partition with loopback device and add the noexec option during mounting. Here is the instructions:

change directory to /var
# cd /var

write a 300MB file
# dd if=/dev/zero of=tmpMnt bs=1024 count=300000

create a ext2 partition on the file
# /sbin/mke2fs /var/tmpMnt

copy current tmp directory content to
# cp -R /tmp /tmp_backup

mount the new /tmp partition
# mount -o loop,noexec,nosuid,rw /var/tmpMnt /tmp

setup correct permission for the new /tmp folder
# chmod 1777 /tmp

copy all previous content of tmp directory to the new old
# cp -R /tmp_backup/* /tmp/

remove unused files
# rm -rf /tmp_backup

create proper symbolic links
# ln -s /tmp /var/tmp

If you want this change to be permanent, add this line at the bottom of your /etc/fstab:
/var/tmpMnt /tmp ext2 loop,noexec,nosuid,rw 0 0

Beside using this method to stop the script kiddies to execute anything from my server tmp directory, I like to change the permission of "wget" (normally used by those script kiddies to download their payload) to owner executable only.

John Wong
Q-Surf Computing Solutions (http://www.q-surf.com/)
Hosting | Web Development | Online Store | Server Administration

[eWebtricity]

Good suggestion, I'll add this to the tutorial section. Thanks JohnWong

[aldee]

Mounting a partition in noexec mode does not add security, since security by obscurity does not exist. You can still run arbitrary code from your tmp partition by supplying the the interpreter for scripts or the dynamic loader for binaries in the command to be run (for binaries this would be /lib/ld-linux.so.2). Nice read: http://www.debian.org/doc/manuals/securing-debian-howto/ch4.en.html#s4.9

[johnwong]

Agreed. This method alone is not a good solution to secure the tmp directory. Unfortunately, the weakest link may be coming from the sites you hosted. For example, one of my clients kept using a bulletin board software for 2 years without updating it. At a result, script kiddies was able to use the software weakness to download and compile a spambot in the /tmp directory. Certainly, asking my clients to update their software may be a solution. However, they either dont have the resources or they are not willing to spend the money to improve their site security. So, my options are:

1) Fix the problems for my clients for free.
2) Cancel the hosting contract with the clients who are not cooperative according to the Terms of Services.
3) Setup multiple defenses (even they are weak defenses) to discourage the script kiddies to hack your box (they may look for other easier target instead). Those defenses may buy you some time to react.

I did the following to protect the tmp directory:
1) mount the tmp directory with noexec option (not secure as mentioned by previous poster)
2) setup a cron job to update some binaries permission to something that cannot be executed by use "apache" daily. Those binaries are the one can download remote files like wget, links, lynx, etc to stop the script kiddies to download their scripts from server. I use a cron job since those binaries may be updated (by yum or up2date) and then I may forget to reset their permissions.
3) Have a cron job to monitor the tmp directory for unusal file

Any other suggestion?