• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

safe_mode isn't for me... :)

EvolutionCrazy

Basic Pleskian
i've an upload script that every moth create a new dir where it will put his files...

i create the dir in this way:
PHP:
if(!file_exists($absolute_path)){
	mkdir ($absolute_path, 0777);
}

that dir in theory should be created with chmod 777...
but in realty it's created with chmod 755 and it's owned by apache:apache... :mad:

there'snt any problem uploading files into that dir if i've safe_mode = Off

but a soon as i set it to On i get "permession denied"... to get the script uploading it correctly again i've to chown that dir to user:psacln and then chmod it 777...

all manually!!!

is this a normal thing?

what have you done to prevent this from happening?
How all your users upload files/create dirs???

did you have a cronjob that chown correctly all the files every 5 min??? :confused:

i hope sw-soft will integrate support for tools like suphp ASAP :( ...
 
Are you the server admin? Have you made sure the chmod() is not in the disabled functions list??

One workaround for your PHP scripts to be able to chmod, would be to implement phpsuexec or similar to allow your script to run with root privs. (Safemode On)

You could put Safemode to Off for just that one domain using .htaccess or vhost.conf

You could put a cron job to run a script to chmod every x minutes, as a workaround this may be acceptable, but eventually the user(s) will be irritated at having to wait x minutes each time....

As a test, see if this works, create a test directory, chmod it to 644 or 755 initially, put the following into a file:

#!/usr/bin/php
<?
$dname = ("test_directory_name")
chmod ($dname, 0777);
?>

run it and see if the perms changed or not.

Another thing to try is:

system('chmod 777 /home/httpd/path_to_directory')

Hope one of these helps.
 
i'm the admin of that server, i've just 2 websites running there and some others sites for my friends....
i was looking to enable safe_mode to a little more security...

actually this is my disabled list:
Code:
disable_functions = system,exec,shell_exec,passthru,proc_open,proc_close,proc_get_status,proc_nice,proc_terminate,popen,pclose

:D

about the upload:

a file uploaded via php (using mod_php) is owned by apache.apache...

and then:

http://www.php.net/chmod

Note: When safe mode is enabled, PHP checks whether the files or directories you are about to operate on have the same UID (owner) as the script that is being executed. In addition, you cannot set the SUID, SGID and sticky bits

so it will not work in any way... (unless you create manually every month a new directory... but i want php make it automatically)

you can chmod only files that you own (with safe_mode On) like dirs or files uploaded via php...

i've tried SUphp but it's not fully compatible with plesk... and the performance are a lower then mod_php

anyone tried directly something like this tools that force directly apache running with differents UID instead of calling PHP with differents UID?

http://httpd.apache.org/docs-2.0/mod/perchild.html

or:
http://www.metux.de/mpm/en/?patpage=index

or:
http://www.telana.com/peruser.php

the last one is too much "invasive" for me... but... the others 2?
 
I belive cron runs as root, so why not run a cron job just before the end of every month to create and chmod/chown a new directory automatically?

I agree about the security aspect, I evaluate every client request fully before giving them safemode off and anything else which could cause a compromise in security. My feeling is unless they want to pay for a dedicated server, they can't have full rights !
 
Originally posted by jamesyeeoc
I belive cron runs as root, so why not run a cron job just before the end of every month to create and chmod/chown a new directory automatically?

i think this is the only way to get this working right....

at least till the time that sw-soft will support suphp or any other similar tool :rolleyes:
 
I would say it's the 'least traumatic' to both you and the server (performance, security,etc). You know, if having to play games (like getting suphp or other stuff) to work properly, or having to open up security holes is needed, but can be resolved by a simple cron job script run once a month, I would go that route.

I hate scripts which 'require' safemode off or other things which open up potential security holes. But this goes with being a host.

A lot of this can be alleviated by many server hardening methods and should be done anyways. (To the others who will no doubt be posting regarding my security comments, I am a firm believer in hardening a server to minimize risks like script exploits etc, I'm just too tired to write well) :D

Personally I don't recommend chmodding to 777 unless there is an overriding reason that a lower perm won't work at all.
 
in the next week i'll retry suphp enabling it on at vhost.conf level only over the domains where i need it...

i hope 0.6.0 version will be really faster then 0.5.2...
 
uhm...

and what about this:
http://www.titov.net/safemodepatch/

sounds good... and i think i know a host that is running a similar solution... (safe mode enabled but you can write and create dir without problems in php... i'm sure that they aren't using suPHP... and php is loaded as module... and apache is running as apache.apache)...

what you think about that?

could be a problem paching a red hat rpm?

and: how can i do that? :D
 
You would not be patching the RedHat rpm, but it would patch the PHP on your system.

As to exactly 'how' to do it, you should refer to the author. If you try his patch, make sure you download the proper version for the version of PHP on your server.

As to how well it will work on a Plesk system, the only advice I can give you is: DO NOT USE A PRODUCTION SERVER FOR TESTING! Always use a separate test server with identical setup to do any testing. After installing *any* software/update/patch, do THOROUGH testing, then do more testing before applying it to a production server.

Also remember that his patch would affect the entire server, not just a particular domain.
 
Not a great solution but you can always use the php ftp commands to create the directory or if you dont have them compiled in simply use sockets to do the job

<?php
$ftp_host="YOURDOMAIN.EXT";
$ftp_user="ftpuser";
$ftp_pass="ftppass";
$basepath="/httpdocs/abcdef/abcdefg";
$name="abcdefgh";
$ftp=fsockopen("$ftp_host",21);
fputs($ftp,"USER $ftp_user\r\n");
fputs($ftp,"PASS $ftp_pass\r\n");
fputs($ftp,"CWD $basepath\r\n");
fputs($ftp,"MKD $name\r\n");
fputs($ftp,"QUIT\r\n");
fclose($ftp);
?>

Agreed its a few more lines but you could always make it a function so you only need to pass the same vars as you do to mkdir if you really wanted too, will save all the hassle of messing around with crons etc.
 
Originally posted by mikk
Not a great solution but you can always use the php ftp commands to create the directory or if you dont have them compiled in simply use sockets to do the job

<?php
$ftp_host="YOURDOMAIN.EXT";
$ftp_user="ftpuser";
$ftp_pass="ftppass";
$basepath="/httpdocs/abcdef/abcdefg";
$name="abcdefgh";
$ftp=fsockopen("$ftp_host",21);
fputs($ftp,"USER $ftp_user\r\n");
fputs($ftp,"PASS $ftp_pass\r\n");
fputs($ftp,"CWD $basepath\r\n");
fputs($ftp,"MKD $name\r\n");
fputs($ftp,"QUIT\r\n");
fclose($ftp);
?>

Agreed its a few more lines but you could always make it a function so you only need to pass the same vars as you do to mkdir if you really wanted too, will save all the hassle of messing around with crons etc.

thanks for you suggestion ;)

the only thing is that i'm a little scared of leaving my ftp password in plain text around my ftp space...

if someone is able to hack my site they can force some of my script to read the source of that file...

till now nothing similar has happened, but i prefer to prevent this keeping my passwords away :)
 
In most cases though if you are running with safemode off you can simply cat /etc/passwd (example) and get a lot of this information anyway.

But do agree that putting passwords in webspace is not really a good idea, it was just suggested as a work around for your problem.
 
Back
Top