Request to add /var/tmp to base_dir

[IT_Architect]

I'm requesting the addition of /var/tmp to base_dir for std php install. I currently must run a script for each install to add it because of apps that require it.

Thanks!

 

[myH2Oservers]

symlink /var/tmp to /tmp and mount /tmp with no-execute thingy ofcourse?

 

[IT_Architect]

symlink /var/tmp to /tmp and mount /tmp with no-execute thingy ofcourse?

You can do that, but there are a couple schools of thought concerning using a symlink for that purpose.
1. /tmp and /var/tmp were originally designed for two different purposes. /tmp is a scratch directory used by the OS for mounting other volumes and file systems, starting GUIs etc. If it becomes full, you can have a major problem, and if you reboot you might be worse off. Thus, it is standard practice to empty the contents of /tmp during the boot. Apps also leverage this expectation of being cleaned to purge dead sessions, etc. /var/tmp was designed for use by applications to store items that depend on them surviving the boot process.

2. Symlinking /var/tmp to /tmp does disk space. Its roots are more cost-driven. It is also widely deployed.

When Unix or Linux are used in the glass house for line-of-business software, the standard is separate partitions for each. The thought is if anything goes haywire in /tmp, it gets cleaned on boot. Application-specific temporary files that normally need to survive boot, do, and if something goes haywire with an app that fills up /var/tmp, you can get at it and clear it.

Since both of these schools of thought have wide-spread acceptance, often software vendors design for the lowest common denominator, which would be the symlink-plus-sticky-bit method if it needs to survive boot. Others ask via a config file for a location that doesn't get cleared on boot, /var/tmp being perfect for this, and some simply expect their stuff won't disappear on boot if they place it in /var/tmp, since the expectation is it does not get cleared on boot. Some software tells you to turn off clearing /tmp on boot, and some just while installing.

Which one people use makes no difference to me but you have to pick one or the other when you install. Number 1 is the one that made the most sense to me personally. That way I don't have to be concerned what happens in /tmp during boot. However, there are a couple points that everyone can agree on.
1. These are both widely deployed schools of thought.
2. If it is acceptable for applications to use /tmp for their temporary files, and even symlink /var/tmp to it, it should be even be more acceptable to allow applications to access to /var/tmp, an area specifically set aside for that purpose.

 

[nobaloney]

Thus, it is standard practice to empty the contents of /tmp during the boot.

I'm very familar with standards for directory structure and usage under posix/linux/unix (though i do occasionally find my recollections are faulty).

My recollection is that you cannot depend on Red Hat / CentOS distributions to clear /tmp on boot. You should, however, check for yourself if you depend on that functionality.

Jeff

 

[IT_Architect]

I agree. Standards all get trumped by the defacto standard which is, there is no standard. I would think it would be pretty much a universal expectation that /var/tmp be included in the open_basedir path. Including it would enable the intended functionality for either method rather than rely on a popular symlink hack to fake /var/tmp, and not work for those who have a real /var/tmp.

 

[myH2Oservers]

I agree. Standards all get trumped by the defacto standard which is, there is no standard. I would think it would be pretty much a universal expectation that /var/tmp be included in the open_basedir path.

Meaning we have to create another partition on installation which is /var/tmp so we can mount it with noexec?

 

[IT_Architect]

Meaning we have to create another partition on installation which is /var/tmp so we can mount it with noexec?

No, it simply means that with the change, open_basedir would provide the intended functionality whether you fake /var/tmp with a symlink or you have a /var/tmp. For those that prefer to fake /var/tmp with a symlink, nothing would change. For those with a real var/tmp, they would no longer have to modify the DA templates every time they do an install to allow their apps to function. The change is completely benign for legacy DA from both a functional standpoint and security standpoint. The only thing that would change is you wouldn't have to hack the templates if you use a real /var/tmp.

 

[gaw]

I am not a fan of this proposal at all.

My custom DA template includes the users homedir in the include path, so the php code can freely use areas above the document root for it's own purposes. I setup a private temp directory for the user in the home directory (also courtesy of DA's custom features).

That eliminates the multi-user tmp mixmaster, temp files get charged against the user's quota, and there is no confusion about what survives a reboot.

 

[IT_Architect]

I am not a fan of this proposal at all. My custom DA template...

You have some interesting thoughts in there but this proposal doesn't affect anything you've just mentioned. You're using custom templates. What I've proposed is supporting the standard directory layout that NIX has used since the beginning. /var/tmp is a temp space specifically set aside for applications to use. Much software is written to use it. That's why when people don't create one, they put in a symlink to fake it so their apps will run. I'm proposing that they not only have /tmp in the path, but also /var/tmp for a whole lot of people who use the NIX standard /var/tmp structure. Currently the open_basedir's default template does not support the standard NIX layout, and apps only work if you fake /var/tmp with a symlink. So currently, to use the standard NIX layout, you need create a custom template.

 

[DirectAdmin Support]

Hello,

Thanks for the discussion. I'll add /var/tmp to the default paths, on the assumption/concensus that it won't really change much, but allow more apps to work correctly without needing to edit the the configs. For anyone who wants something else.. that's why we have templates, so that they can be modified. Adding the extra path won't break any existing scripts, but will fix existing broken ones that need /var/tmp.

John

 

[myH2Oservers]

Hello,

Thanks for the discussion. I'll add /var/tmp to the default paths, on the assumption/concensus that it won't really change much, but allow more apps to work correctly without needing to edit the the configs. For anyone who wants something else.. that's why we have templates, so that they can be modified. Adding the extra path won't break any existing scripts, but will fix existing broken ones that need /var/tmp.

John

And what about the security? We mount /tmp with noexec etc. to avoid people abusing the /tmp. Now you are putting another path into the open basedir so people can start uploading to /var/tmp and execute things.. because /var/tmp isn't a default partition.

I suggest to remove /var/tmp from the open basedir, people who need it can use the templates to have it their way. You are now turning the world upside down

 

[IT_Architect]

Thanks for the discussion. I'll add /var/tmp to the default paths...allow more apps to work correctly without needing to edit the the configs.

Perfect!! I wouldn't ask to support a non-starndards-based path in the default configs, only a change to support the standard NIX layout. By doing so, the need to create a custom template would be eliminated for many installs.

And what about the security? We mount /tmp with noexec etc. to avoid people abusing the /tmp. Now you are putting another path into the open basedir so people can start uploading to /var/tmp and execute things.. because /var/tmp isn't a default partition

For anyone who uses the symlink method, they both resolve to /tmp, which means it is simply two paths to the same place and thus security is governed by whatever they have setup up for /tmp. For those who use the conventional NIX layout with a real /var/tmp, they already have /var/tmp secured just as they do /tmp. DirectAdmin doesn't secure either of them. The only difference is OS installs that use a real /var/tmp, need to hack the standard templates to get standards-based behavior. It is common for apps to look for the standard applications temp directory, /var/tmp, so it's not like it is optional. The path will be there to it by either adding it to open_basedir or a /var/tmp symlink. The only thing that changes when added to the open_basedir is we don't need to make a custom template for the standard NIX structure.

Thanks!

 

[DirectAdmin Support]

Hello,

I've also seen many reports of php script errors that are trying to get to /var/tmp, if it worked by default, that would save everyone some headaches.

Regardings security, I won't leave you hanging. As mentioned by IT_Architect, a simple symlink is all that's need to resolve that.

For existing systems, you'd do

cd /var
rm -rf tmp
ln -s /tmp ./tmp

I would also be willing to add that code to the installer if anyone see's this as being an issue. Keep in mind as IT_Architect mentioned, we do not change the noexec,nosuid options in the /etc/fstab, that's an admin decision (which we do recommend) so it would again be up to the admin to jump through this hoop on the update. I'll make a note about it in the versions system.

I will leave this open if there are any more comments or concerns. I did put

on the assumption/concensus that it won't really change much

if there are any new piece of information anyone would like to add, or sugestions how to solve both sides (like deciding the above code is a good idea to add to DA during updates for existing systems), then let me know.

John