How to enable "proc_open" for one user?

What functions do you have disabled in the php.ini file that php-fpm is using?

Any functions included there cannot be enabled any where else.

So if you have proc_open disabled in your php.ini file, then you won't be able to enable it for any users in their php-fpm pool file.

If you want proc_open enabled for a particular user, then you have to remove proc_open from the php.ini file, then add it to all of the disabled_functions php_admin_value directive for all of the php-fpm pools. Then remove it from the disabled_functions php_admin_value for the pool that you want it enabled on.
 
I have php5 and php 7 installed. I set the settings for php 7 since that is the version I am using.
I restarted the php-fpm.service

Okay I will create a ticket there :o
 
Hello, I'm facing the same issue.

An account needs to enable proc_open which is disabled globally.

If I disable it globally it works but if I try an override only for that single user it doesn't work...

The Process class relies on proc_open, which is not available on your PHP installation.

I did the modification as @ditto reported and in my phpinfo() I don't see the function blocked
 

Attachments

  • FireShot Capture 025 - phpinfo.png
    FireShot Capture 025 - phpinfo.png
    30.3 KB · Views: 49
maybe it need "popen"? try te enable it too

nope... popen enabled too but no luck...


./data/users/xxxxxxx/php/php-fpm72.conf

php_admin_value[disable_functions] = exec,system,passthru,shell_exec,dl,show_source,posix_kill,posix_mkfifo,posix_getpwuid,posix_setpgid,posix_setsid,posix_setuid,posix_setgid,posix_seteuid,posix_setegid,posix_uname
 
The disable_functions can only be set once in the main php.ini file, and cannot be overridden by other areas. You need to remove it from php.ini file then and set it php-fpmXX.conf for all users with different values.

Note, in this case PHP cli won't have the disable_functions at all.
 
Is this still only option?

I would like to enable proc_close on one account. I need to manually modify every conf on all the accounts on the sever? o_O

DA please have a mercy
 
Last edited:
Hello guys,

Apologies for digging this thread but how do I enable proc_open for a single user on CloudLinux using LSAPI?

Thank you!
 
Last edited:
Hi Guys,

I had a ticket today with the same question so figured I'd follow it up here.
As zEitEr mentioned, disable_functions cannot be listed the php.ini if they're ever to be used later on, else (I'm guessing) php won't load them into memory or ever allow their use later on. The solution is to do the inverse, enable them at load, but disable them later on.

This guide is how you'd just "defer" when a function is disabled, to be done in the per-user php-fpm config, but system globally, so you don't have to do it for each user. With this method, you can just override the disable_functions list on a per-user basis, later on via the GUI.
  1. Don't block functions wih the php.ini:
    Code:
    da build set secure_php no
    da build php_ini
  2. Create 2 system global template token configs with the following code:
    /usr/local/directadmin/data/templates/custom/php-fpm.conf.custom1
    Code:
    |?DF=php_admin_value[disable_functions] = exec,system,passthru,shell_exec,proc_close,proc_open,dl,popen,show_source,posix_kill,posix_mkfifo,posix_getpwuid,posix_setpgid,posix_setsid,posix_setuid,posix_setgid,posix_seteuid,posix_setegid,posix_uname|

    /usr/local/directadmin/data/templates/custom/php-fpm.conf.custom2
    Code:
    |DF|

    This will set the listed disable_functions list to all Users on the system after their data/users/fred/php/php-fpm83.conf is rewritten:
    Code:
    da build rewrite_confs
  3. Disable proc_open for any Users that needs it by going to:
    Admin Level » Custom Httpd Config » domain.com - php-fpm 8.3
    and in the "php-fpm Global |CUSTOM 1|" token area, add the line to override the first, without proc_open, eg:
    Code:
    |?DF=php_admin_value[disable_functions] = exec,system,passthru,shell_exec,dl,popen,show_source,posix_kill,posix_mkfifo,posix_getpwuid,posix_setpgid,posix_setsid,posix_setuid,posix_setgid,posix_seteuid,posix_setegid,posix_uname|
and hit save. View the resulting php-fpm config, and the DF variable in user global CUSTOM 1 should have overridden the system global CUSTOM 1.
You'll need to restart php-fpm83 after making the changes.

Note, I'm calling "System Global" the files saved in the data/templates/custom directory, and the "User Global" the value in the GUI which refers to all php versions of that User. Apologies for the confusion double use of the term "Global" :)

John
 
NOTE:
The custombuild "secure_php=yes" option does more than just setting the disable_functions.

You may want to alternatively keep the other options on, so do:
Code:
da build set secure_php yes
da build set php_ini yes
da build php_ini
da build set php_ini no
php --ini

and manually edit the main php.ini listed from the `php --ini` call, and manually comment out the disable_functions option.
This will leave the other secure_php options turned on, but respect your manual changes.
 
Hi Guys,

I had a ticket today with the same question so figured I'd follow it up here.
As zEitEr mentioned, disable_functions cannot be listed the php.ini if they're ever to be used later on, else (I'm guessing) php won't load them into memory or ever allow their use later on. The solution is to do the inverse, enable them at load, but disable them later on.

This guide is how you'd just "defer" when a function is disabled, to be done in the per-user php-fpm config, but system globally, so you don't have to do it for each user. With this method, you can just override the disable_functions list on a per-user basis, later on via the GUI.
  1. Don't block functions wih the php.ini:
    Code:
    da build set secure_php no
    da build php_ini
  2. Create 2 system global template token configs with the following code:
    /usr/local/directadmin/data/templates/custom/php-fpm.conf.custom1
    Code:
    |?DF=php_admin_value[disable_functions] = exec,system,passthru,shell_exec,proc_close,proc_open,dl,popen,show_source,posix_kill,posix_mkfifo,posix_getpwuid,posix_setpgid,posix_setsid,posix_setuid,posix_setgid,posix_seteuid,posix_setegid,posix_uname|

    /usr/local/directadmin/data/templates/custom/php-fpm.conf.custom2
    Code:
    |DF|

    This will set the listed disable_functions list to all Users on the system after their data/users/fred/php/php-fpm83.conf is rewritten:
    Code:
    da build rewrite_confs
  3. Disable proc_open for any Users that needs it by going to:
    Admin Level » Custom Httpd Config » domain.com - php-fpm 8.3
    and in the "php-fpm Global |CUSTOM 1|" token area, add the line to override the first, without proc_open, eg:
    Code:
    |?DF=php_admin_value[disable_functions] = exec,system,passthru,shell_exec,dl,popen,show_source,posix_kill,posix_mkfifo,posix_getpwuid,posix_setpgid,posix_setsid,posix_setuid,posix_setgid,posix_seteuid,posix_setegid,posix_uname|
and hit save. View the resulting php-fpm config, and the DF variable in user global CUSTOM 1 should have overridden the system global CUSTOM 1.
You'll need to restart php-fpm83 after making the changes.

Note, I'm calling "System Global" the files saved in the data/templates/custom directory, and the "User Global" the value in the GUI which refers to all php versions of that User. Apologies for the confusion double use of the term "Global" :)

John
This info is GOLD, Thank you 🤩🤩!

I had an argument with a software developer a few weeks back as the software i'd paid out for to work with WHMCS was erroring out spectacularly. They wanted PHP 8.2 minimum and up to date database. Upon digging into the logs it was something I couldn't fix as they used PHP Ioncube to encode the source. I gave them the logs and told them it's their issue. They were adamant it was my server setup and told me to disable exec and shell_exec. I told them I wasn't happy doing this as it's proper unsafe in certain situations but relented and tried my best to disable it, but hit so many obstacles with the FPM setup and the secure_php. Luckily enough another coder got in on the conversation and fixed the software problem as it was their end, not my DA setup.

Could I please request this info above be put in the main DA Wiki so it doesn't get lost? I know not a lot of people will ever need it, but for something like what happened to me above, that info at the time would've been amazing to prove a point to the developers.

Thanks again, (I've bookmarked this thread)

Alan
 
Back
Top