problem with special permision with php wonder which to use(suphp or ruid)?

N

netseeker

Verified User
Joined
Apr 20, 2010
Messages
14
Hi,

I have problem with using joomla during upload a picture or any other scripts that need some special permission say uploading or editing a physical page on the server.
turns out I've fixed the problem with the help of "CHOWN" command like following:

Code: 
chown -R apache:apache *

but after applying this trick ftp users will face problem, cause the folder they have access to it is now owned by apache user.

after few searches in forum I've found two solution:
1-suPHP
2-ruid

for now I have around 10 real working websites on my vps and I can't afford(a.k.a pay fine to my customers) any failure.
I want everything works well as well as this php thing get solved.

what should I do?
shall I go with ruid_mod? is it safe ? will it be install without any problem?

my DA version is : 1.36.2
my OS : centOS 5.0

p.s :
Why DA guys don't care about solving this problem in the core , then afetr we have to find a solution in the forum?
with these kind of buggy things in DA , DA won't be shining like cpanel or anyother competitors around.
please solve this fundamental problem at least for the sake of more money.
 
Last edited:
IMHO this is no buggy DA stuff but rather shortcomings of Joomla. You almost won't find this kind of problem with Wordpress. Except for some things like upload/editing maybe.

I don't find chown apache:apache a solution. Normally when you have to upload and edit things in joomla, you should chmod 777 the directory on which this is done. That way you wouldn't have any problem with ftp users working on it.

There are various opinions about mod_ruid and suPHP. SuPHP makes scripts run under the username, but you can't use 777 anymore, which is good from one side, but can have disadvantages by some applications.

Mod_ruid is faster, but also has some disadvantages. I believe some are using both suphp and mod_ruid.

Personally I use mod_ruid without suphp. Mod_ruid is easy to install, there is a good manual for it in the da help section.
Suphp can be easily installed by the tools.update script (3rd party) which is also on this forum and good supported.
Choice is up to you.
 
@Richard G

A bit offtopic, but:

We did try using both suphp and mod_ruid, but it failed.
In suphp.conf there is an option, which sets account name, from which you can call suphp:

Code: 
webserver_user=apache

In case you use mod_ruid, it's never an apache user, who calls suphp. Thus one gets an error.
 
I didn't use it both too, but I think I remember Tomtom901 once said he installed them both via the tools.update script. However, it could be this was not at the same time.
That's why I wrote that I believed some were doing that, because I wasn't sure about it.
Because I know some things would conflict.
But thank you for pointing it out. I also think it's better to choose between one of them.
 
But it's still possible to use them at the same time, I think, on the server but for different vhosts. Thus one need to do some work and configure virtual hosts' templates in order to let an user or admin to switch what to use on particular virtual host: suPHP, or mod_ruid. In that case where should not be any conflict.

Some kind of a plugin to switch between PHP-CGI (mod_suphp) and PHP (mod_php/mod_ruid).
 
That could be the case, but imho you indeed should have a plugin or manually adjust things to get it to work.
I would'nt know for sure, we don't use suphp, but only mod_ruid.
 
@Richard G:

I read somewhere on these forums of a vulnerability that when using mod_ruid if apache is ever compromised then someone can use it to switch to any user. Any comments on that? We're still use PHP as CGI but I think mod_ruid is more serverload-efficient. But security is important to us; what are your thoughts?

Jeff
 
As far as I know there is indeed the apache compromise question with mod_ruid. I've also read that on a couple of webhosting forums. In case of an Apache breach a user could get root access. But as far as I know this has not happened anywhere yet.

I'm not sure if this is also the case with mod_ruid2, I did not have time enough yet to get a good look at it yet.

When switching to mod_ruid things work faster and until yet we don't have had any issue that a problem could get further then a users homedir.

But with the eye on security it's really a must to keep php and apache up to date and if possible put some security in php, like at least disable the dl() function in php.ini.

At this moment there are several Dutch hosters which use mod_ruid for several years to their satisfactory.
As for myself I can only see that I might not have enough experience with it, because I'm only running it about 1,5 year. So these are indeed just my thoughts about it.
 
Last edited:
Absolutly Richard, I like using mod_ruid, mostly because it is faster then PHP in (fast)CGI mode, and it does not throw internal servererrrors when a client chmods a directory to 777.

Mod_ruid, indeed has a bug with the apache webserver as mentioned before, but there has been some improvement on this point.

I think Jeff, that keeping your system secure is an important issue, but as far as I go in this, with some securing in the php.ini (magic quotes, enable_dl(), disabled functions) and on top on that Suhosin (PHP hardening patch), which I installed using the install.script. I myself compile mod_ruid from source.

@Jeffs question concerning the changes that must be made: No, I can compile mod_ruid in 10 lines of code (and working). Suhosin is up to you, but by using the install.script it does not take that much of a work.
 
Is it possible to set an individual php.ini per user with mod_ruid without using option PHP_INI_SCAN_DIR?

We give our users individual php.ini with suPHP.
 
@zEiTeR: I just tried, I put a php.ini under a user, it gives no error notice, but changes made in the users php.ini won't show up. So I'm afraid it won't work without additional settings.

@Jeff: If you are referring to all the chmod changes and so on, no that is not necessary. Just some custom httpd.conf files.
I also compile it from source as Tomtom901 does. It's very easy, there is a howto on the DA forums by a Dutch Engineer called Randy. His core business is server security and maintenance/management/support.
You can follow his howto here:
http://directadmin.com/forum/showpost.php?&p=164208&postcount=31

The only changes needed really are to change the mod_ruid version to the newest version or to mod_ruid2.
So last time I used: http://sourceforge.net/projects/mod-ruid/files/mod_ruid2/mod_ruid2-0.9.1.tar.bz2
 
Thanks, but a few more questions...

Do I have to undo any of those changes, then, if switching to mod_ruid2 FROM PHP as CGI?

How much downtime might I have while converting from PHP as CGI?

How much downtime might I have while converting from mod_php to mod_ruid2/

I realize I'll need to look at any custom php.ini before I do the conversion so it may not be possible if any users are actually using their own php.ini files.

But I do want to look into it.

Thanks.

Jeff
 
Do I have to undo any of those changes, then, if switching to mod_ruid2 FROM PHP as CGI?
Click to expand...
Yes, there would be probably some changes needed, in any case scripts which normally would need 777 on f.e. an upload directory would have to be set from 755 or whatever it is now, to 777 I guess.

As much as I would like to answer your questions, I can't. Because I never used suphp and cgi or fastcgi so I wouldn't know how much time conversion will costs and how much downtime it would give.

I do straigt from the standaard DA installation, security first (/tmp etc. firewalling and stuff) and after that I do mod_ruid2.
The installation of mod_ruid2 takes not even 10 minutes without downtime.

So I hope maybe Tomtom or somebody else can shed his light on your questions to answer then more specifically because I really don't know the answer myself.

As for the php.ini I don't know either but our users noramally use their needed php settings in .htaccess files.
 
Yes, there would be probably some changes needed, in any case scripts which normally would need 777 on f.e. an upload directory would have to be set from 755 or whatever it is now, to 777 I guess.
Click to expand...

Nothing of that kind. 777 is needed only when, PHP scripts, that write any files to a certain directory, are running from a different user, not an user owner of the account.
 
I'm sorry, you are correct, I mixed up mod_ruid and cpanels apache suexec.

However there are still some scripts around which are not scripted optimal and have a 777 check in them which don't know about mod_ruid. They only look if a directory is 777 or not and when it's not, it's going to give errors or won't install.

When having a lot of servers and users, big chance that there will be some of these kind of scripts installed and users will change directory's to 777.
 
zEitEr said:
Is it possible to set an individual php.ini per user with mod_ruid without using option PHP_INI_SCAN_DIR?

We give our users individual php.ini with suPHP.
Click to expand...

PHP_INI_SCAN_DIR is ignored when using mod_php. And PHPIniDir can be used only once in http.conf.

Found answer on my question here: http://bugs.php.net/bug.php?id=35684&edit=1

Apparently it is impossible just because an apache child may serve requests to different virtual hosts, but it loads PHP module (and reads php.ini) only once - during the initial startup.
Click to expand...

With mod_php I did not found a way to set up distinct php.ini for each user.
 
You must log in or register to reply here.
Back
Top