What to do with mod_ruid2?

Anne

Anne

Verified User
Joined
Dec 3, 2015
Messages
71
Hi,

According to this announcement, mod_ruid2 will be dropped.

DirectAdmin/CustomBuild: Removal of suPHP, mod_ruid2, mod_php, MySQL 5.5/5.6, MariaDB 5.5/10.0/10.1/10.2

DirectAdmin intends to remove support of some outdated software: * suPHP - (EOL 2013) - DA support will be dropped on 2023-01-01 * mod_ruid2 - (compatible with CentOS 7 only) - DA support will be dropped on 2023-01-01 * mod_php - DA support will be dropped on 2023-01-01 * MySQL 5.5, 5.6 - (EOL...
forum.directadmin.com forum.directadmin.com

I have a server with this module on it, I get a message from DA about that support will be removed soon: "Support of mod_ruid2 will be removed soon, please switch to another mode of PHP."

All fine by me. But now I wonder what I must do? It's not really clear to me. Do I need to replace it with something? Is it even running in the first place? My PHP runs in FPM/FastCGI mode and I read mod_ruid2 is a suexec module?

Please help me out. What do I need to check and what are the actions I must take here? Thanks a lot!
 
mod_ruid2 use for mod_php, So it removal on same day. php-fpm don't need it.
 
Hi,

Thanks Jam, so removing them should not effect anything?

Hi ZEitEr, these are the build options you want to know I think:

mod_ruid2: 0.9.8
PHP (default): 7.4 as php-fpm
PHP (additional): 8.1 as php-fpm
Click to expand...
 
Last edited:
@Anne
Yes, remove "mod_ruid2" should be fine. your server use only "php-fpm", it not effect anything from remove this extension.
 
Thank you.

So this is a simple one too. That is nice, no more messages for me. I will run this at a low traffic moment later today.

./build set mod_ruid2 no
./build rewrite_confs
Click to expand...
 
What are the suggested alternatives for static files? (eg: upload dirs where the upload is handled by php)
 
Doesn't ruid2 also work for static file? (have been doing fpm for a long time)
 
Ruid2 is not ment to be used in combination with php-fpm. It was only created to be used with mod_php to make things more safe so all files were presented as being from the user instead of apache. Which also removed the need to create 777 directory's and 666 files which was unsafe.
So it was ment as suexec module for apache, but it was safer too as there was no need for files and/or directory's (static or dynamic) to be owned by apache anymore and all files got owned by the user.

As soon as you change to php-fpm, the need for ruid2 was gone. Static and dynamic files will still have the user as owner and you still don't need any chmod 777 or 666 anymore.
Unless there is some bad programmed script which doens't check correctly. ;)
 
My point is the following (and which is why I use php-fpm + ruid2 for many years):

- user uploads files, handled via php. Php runs fpm, so runs as `myuser`.
- file (image) is resized (by php) and saved in `/home/myuser/public_html/uploads/something.png`
- user has a umask in place and the file is generated is 600
- if you then browse to myusr.site.tld/uploads/something.png, the file is served by Apache, using the `apache` user

If I am not mistake, ruid2 solved this, by serving the file itself using instead of return permission denied.
 
That's bad coding. Why you still using upload and show real file like that. If you upload with php, you should make function to download or show with php too. this way, it safe 100%.
 
Frank said:
- user has a umask in place and the file is generated is 600
Click to expand...
Why should you do that if you want to have the file world readable via the browser.
Normally an uploaded file gets owned by the user and chmod 644 and then there is no issue visiting it via the browser either. Even Wordpress is doing it that way.
Or use the method suggested by jamgames2.

Something is off or bad coded, because apache owner should never be present anymore at php-fpm sites.

When you use the browser, how do you see it's presented by the apache user?
 
jamgames2 said:
That's bad coding. Why you still using upload and show real file like that. If you upload with php, you should make function to download or show with php too. this way, it safe 100%.
Click to expand...
You've clearly never seen sites with 1000's of downloads per second... You do NOT want php to serve those
 
Richard G said:
When you use the browser, how do you see it's presented by the apache user?
Click to expand...
Lol, because it's served by apache, straight of the docroot?

Anyway, it seems I am the only one who used ruid2 for static files. I was already considering ditching DA in the future for this host, I guess I'll have to move that up my priority list.
 
Frank said:
Lol, because it's served by apache, straight of the docroot?
Click to expand...
That would mean that the owner is apache and not the user, correct? If that is the case, then the script is not coded correctly.
Every upload should get the user as owner and chmod 644 and everybody can access it directly without issues, no need for mod_ruid2.
 
Of course the user is the owner, as it's created by php (please read up on what I typed before).

In terms of "bad programming". Sigh. I'm not going into a debate if chmod 600 or chmod 644 is the most secure. (Hint: think about other users on the system). Point is: ruid2 solved it, it's now no longer supported. Which is sad.
 
Frank said:
(please read up on what I typed before).
Click to expand...
You might do that too.
I was investigating as to how you were verifying that the file was presented as apache since it should be owned by the user (which is indeed the fact as you say). That seems bad programming somewhere to me. So I want to check on our systems to verify some things, that was the reason I was asking.

As for the 644 and 600, there is no debate about most secure, I didn't mention anything about security in my comments about 600 and 644.
I wasn't talking about more secure but how to present it to outside via the browser and comparing as to how Wordpress it also does, and was just asking why you used 600. I never used the word secure, so please don't jump to wrong conclusions about questions being made.

If you want it presented via browser anyway, then other users on the system don't matter because they can get to it via the browser anyway. And as far as I know other users do not get into other home directory's if you have the open basedir protection enabled either.

Anyway, ruid2 is indeed no longer supported because mod_php isn't anymore where it was ment for. Probably other panels will follow on that later on.
Sad, yes, I didn't like it either, but well.... modernisation is a fact of life. Not always a pleasant fact unfortunately.
 
So there's a difference between "owned" and "served". As it's a static file, with no php wrapper in between, it's being served by apache, so by the apache or www-data user (depending on your env). That's not "Bad Programming" as there's nothing in the programming which can be done to influence that.

The rest of the arguments I'm just going to skip, I advise you to reread everything.

The last paragraph brings me back to my original point: ruid2 has a LOT of usages outside of php.I've ran php-fpm for 8 years in combination with ruid2. The fact that a lot of people used it as an alternative to fpm, doesn't mean it has no use outside of php or even (f)cgi in a broader context.
 
You must log in or register to reply here.
Back
Top