Bug #65100 [Csd]: Reject root run
Edit report at https://bugs.php.net/bug.php?id=65100&edit=1 ID: 65100 User updated by:admin at mvpro dot net Reported by:admin at mvpro dot net Summary:Reject root run Status: Closed Type: Bug Package:FPM related Operating System: Linux Debian Wheezy PHP Version:5.5.0 Assigned To:fat Block user comment: N Private report: N New Comment: Proccess priority works...i am stupid, sorry. Closed. Previous Comments: [2013-06-24 16:37:23] admin at mvpro dot net Umm, ok with -R it's OK. It's not the best way to modify /etc/init.d fpm files manually, so ideally i think you should allow root by default. You should change type of root message to warning. I am sure you need to inform users about the issue with root, but it should not make php5-fpm fail to start. [2013-06-24 16:29:40] dlsni...@php.net Hi, I've forgot to mention that if you run: php-fpm help it will show you something like this: Usage: php-fpm [-n] [-e] [-h] [-i] [-m] [-v] [-t] [-p ] [-g ] [-c ] [-d foo[=bar]] [-y ] [-D] [-F] [...] -R, --allow-to-run-as-root Allow pool to run as root (disabled by default) Have you tried that? Thanks :) [2013-06-24 16:21:06] admin at mvpro dot net dlsniper, i have nothing against such policy, however it would be interesting to know what issues can it do. I have many scripts which can not get access to php files because of bad chmod. I can set it automatically but it's rather bad to do it via cron every minute, because it will affect perfomance. Also it will not 'at the moment', maybe user have to wait for a minute after a file update. It's not really awesome. I think it's a bug because in PHP 5.5 there are invent: "; Specify the nice(2) priority to apply to the master process (only if set) ; The value can vary from -19 (highest priority) to 20 (lower priority) ; Note: - It will only work if the FPM master process is launched as root ; - The pool process will inherit the master process priority ; unless it specified otherwise ; Default Value: no set process.priority = -19" This new feature is useless, when root user cause fail to load php-fpm. If root issue is permanent, then why is proccess.priority was implemented? [2013-06-24 16:13:20] dlsni...@php.net Hi, I'm using Ubuntu 13.04 and I've compiled PHP 5.5 with FPM from sources. I do indeed get something like this: [24-Jun-2013 18:09:32] ERROR: [pool default] please specify user and group other than root [24-Jun-2013 18:09:32] ERROR: FPM initialization failed but I don't think it is a bad thing. Running PHP with root as user would be considered a major security issue so maybe it's not really a bug. Can you provide a real use case where you'd want to allow a script executed via FPM to have root privileges as I can't think of a good one right now? Thanks. -------------------- [2013-06-23 03:36:07] admin at mvpro dot net Description: Php5-fpm rejected to run with user 'root' and group 'root', it fails to load. While proccess priority was implemented, i assume, running PHP-fpm with user 'root' should be allowed. Test script: --- Put in /etc/php5/fpm/pool.d/www.conf user = root Expected result: Success run. Actual result: -- Fail to run. -- Edit this bug report at https://bugs.php.net/bug.php?id=65100&edit=1
Bug #65100 [Asn->Csd]: Reject root run
Edit report at https://bugs.php.net/bug.php?id=65100&edit=1 ID: 65100 User updated by:admin at mvpro dot net Reported by:admin at mvpro dot net Summary:Reject root run -Status: Assigned +Status: Closed Type: Bug Package:FPM related Operating System: Linux Debian Wheezy PHP Version:5.5.0 Assigned To:fat Block user comment: N Private report: N New Comment: Umm, ok with -R it's OK. It's not the best way to modify /etc/init.d fpm files manually, so ideally i think you should allow root by default. You should change type of root message to warning. I am sure you need to inform users about the issue with root, but it should not make php5-fpm fail to start. Previous Comments: [2013-06-24 16:29:40] dlsni...@php.net Hi, I've forgot to mention that if you run: php-fpm help it will show you something like this: Usage: php-fpm [-n] [-e] [-h] [-i] [-m] [-v] [-t] [-p ] [-g ] [-c ] [-d foo[=bar]] [-y ] [-D] [-F] [...] -R, --allow-to-run-as-root Allow pool to run as root (disabled by default) Have you tried that? Thanks :) [2013-06-24 16:21:06] admin at mvpro dot net dlsniper, i have nothing against such policy, however it would be interesting to know what issues can it do. I have many scripts which can not get access to php files because of bad chmod. I can set it automatically but it's rather bad to do it via cron every minute, because it will affect perfomance. Also it will not 'at the moment', maybe user have to wait for a minute after a file update. It's not really awesome. I think it's a bug because in PHP 5.5 there are invent: "; Specify the nice(2) priority to apply to the master process (only if set) ; The value can vary from -19 (highest priority) to 20 (lower priority) ; Note: - It will only work if the FPM master process is launched as root ; - The pool process will inherit the master process priority ; unless it specified otherwise ; Default Value: no set process.priority = -19" This new feature is useless, when root user cause fail to load php-fpm. If root issue is permanent, then why is proccess.priority was implemented? [2013-06-24 16:13:20] dlsni...@php.net Hi, I'm using Ubuntu 13.04 and I've compiled PHP 5.5 with FPM from sources. I do indeed get something like this: [24-Jun-2013 18:09:32] ERROR: [pool default] please specify user and group other than root [24-Jun-2013 18:09:32] ERROR: FPM initialization failed but I don't think it is a bad thing. Running PHP with root as user would be considered a major security issue so maybe it's not really a bug. Can you provide a real use case where you'd want to allow a script executed via FPM to have root privileges as I can't think of a good one right now? Thanks. -------------------- [2013-06-23 03:36:07] admin at mvpro dot net Description: Php5-fpm rejected to run with user 'root' and group 'root', it fails to load. While proccess priority was implemented, i assume, running PHP-fpm with user 'root' should be allowed. Test script: --- Put in /etc/php5/fpm/pool.d/www.conf user = root Expected result: Success run. Actual result: -- Fail to run. -- Edit this bug report at https://bugs.php.net/bug.php?id=65100&edit=1
Bug #65100 [Asn]: Reject root run
Edit report at https://bugs.php.net/bug.php?id=65100&edit=1 ID: 65100 User updated by:admin at mvpro dot net Reported by:admin at mvpro dot net Summary:Reject root run Status: Assigned Type: Bug Package:FPM related Operating System: Linux Debian Wheezy PHP Version:5.5.0 Assigned To:fat Block user comment: N Private report: N New Comment: dlsniper, i have nothing against such policy, however it would be interesting to know what issues can it do. I have many scripts which can not get access to php files because of bad chmod. I can set it automatically but it's rather bad to do it via cron every minute, because it will affect perfomance. Also it will not 'at the moment', maybe user have to wait for a minute after a file update. It's not really awesome. I think it's a bug because in PHP 5.5 there are invent: "; Specify the nice(2) priority to apply to the master process (only if set) ; The value can vary from -19 (highest priority) to 20 (lower priority) ; Note: - It will only work if the FPM master process is launched as root ; - The pool process will inherit the master process priority ; unless it specified otherwise ; Default Value: no set process.priority = -19" This new feature is useless, when root user cause fail to load php-fpm. If root issue is permanent, then why is proccess.priority was implemented? Previous Comments: [2013-06-24 16:13:20] dlsni...@php.net Hi, I'm using Ubuntu 13.04 and I've compiled PHP 5.5 with FPM from sources. I do indeed get something like this: [24-Jun-2013 18:09:32] ERROR: [pool default] please specify user and group other than root [24-Jun-2013 18:09:32] ERROR: FPM initialization failed but I don't think it is a bad thing. Running PHP with root as user would be considered a major security issue so maybe it's not really a bug. Can you provide a real use case where you'd want to allow a script executed via FPM to have root privileges as I can't think of a good one right now? Thanks. ---------------- [2013-06-23 03:36:07] admin at mvpro dot net Description: Php5-fpm rejected to run with user 'root' and group 'root', it fails to load. While proccess priority was implemented, i assume, running PHP-fpm with user 'root' should be allowed. Test script: --- Put in /etc/php5/fpm/pool.d/www.conf user = root Expected result: Success run. Actual result: -- Fail to run. -- Edit this bug report at https://bugs.php.net/bug.php?id=65100&edit=1
[PHP-BUG] Bug #65100 [NEW]: Reject root run
From: admin at mvpro dot net Operating system: Linux Debian Wheezy PHP version: 5.5.0 Package: FPM related Bug Type: Bug Bug description:Reject root run Description: Php5-fpm rejected to run with user 'root' and group 'root', it fails to load. While proccess priority was implemented, i assume, running PHP-fpm with user 'root' should be allowed. Test script: --- Put in /etc/php5/fpm/pool.d/www.conf user = root Expected result: Success run. Actual result: -- Fail to run. -- Edit bug report at https://bugs.php.net/bug.php?id=65100&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65100&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65100&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65100&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65100&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65100&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65100&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65100&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65100&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65100&r=support Expected behavior: https://bugs.php.net/fix.php?id=65100&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65100&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65100&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65100&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65100&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65100&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65100&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65100&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65100&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65100&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65100&r=mysqlcfg
Bug #65099 [Csd]: Errors displayed always regardless of setting display_errors
Edit report at https://bugs.php.net/bug.php?id=65099&edit=1 ID: 65099 User updated by:admin at mvpro dot net Reported by:admin at mvpro dot net Summary:Errors displayed always regardless of setting display_errors Status: Closed Type: Bug Package:*General Issues Operating System: Linux Debian Wheezy PHP Version:5.5.0 Block user comment: N Private report: N New Comment: You should definitely remove this bug report :) Previous Comments: [2013-06-23 02:53:45] admin at mvpro dot net Wow, i stupid... [2013-06-23 02:51:04] admin at mvpro dot net Description: It's strange, but i have "display_errorsOff Off display_startup_errors Off Off" and errors still shown. For example i have: "Deprecated: mysql_pconnect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in bla bla bla on line 23" Using php5-fpm - PHP Version 5.5.0-1~dotdeb.1 Zend Engine v2.5.0-dev, Copyright (c) 1998-2013 Zend Technologies with Zend OPcache v7.0.2-dev, Copyright (c) 1999-2013, by Zend Technologies with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans Web server: Nginx Test script: --- In php.ini: display_errors = Off display_startup_errors = Off Expected result: I expect no errors shown! Actual result: -- Errors shown... -- Edit this bug report at https://bugs.php.net/bug.php?id=65099&edit=1
Bug #65099 [Opn->Csd]: Errors displayed always regardless of setting display_errors
Edit report at https://bugs.php.net/bug.php?id=65099&edit=1 ID: 65099 User updated by:admin at mvpro dot net Reported by:admin at mvpro dot net Summary:Errors displayed always regardless of setting display_errors -Status: Open +Status: Closed Type: Bug Package:*General Issues Operating System: Linux Debian Wheezy PHP Version:5.5.0 Block user comment: N Private report: N New Comment: Wow, i stupid... Previous Comments: [2013-06-23 02:51:04] admin at mvpro dot net Description: It's strange, but i have "display_errorsOff Off display_startup_errors Off Off" and errors still shown. For example i have: "Deprecated: mysql_pconnect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in bla bla bla on line 23" Using php5-fpm - PHP Version 5.5.0-1~dotdeb.1 Zend Engine v2.5.0-dev, Copyright (c) 1998-2013 Zend Technologies with Zend OPcache v7.0.2-dev, Copyright (c) 1999-2013, by Zend Technologies with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans Web server: Nginx Test script: --- In php.ini: display_errors = Off display_startup_errors = Off Expected result: I expect no errors shown! Actual result: -- Errors shown... -- Edit this bug report at https://bugs.php.net/bug.php?id=65099&edit=1
[PHP-BUG] Bug #65099 [NEW]: Errors displayed always regardless of setting display_errors
From: admin at mvpro dot net Operating system: Linux Debian Wheezy PHP version: 5.5.0 Package: *General Issues Bug Type: Bug Bug description:Errors displayed always regardless of setting display_errors Description: It's strange, but i have "display_errorsOff Off display_startup_errors Off Off" and errors still shown. For example i have: "Deprecated: mysql_pconnect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in bla bla bla on line 23" Using php5-fpm - PHP Version 5.5.0-1~dotdeb.1 Zend Engine v2.5.0-dev, Copyright (c) 1998-2013 Zend Technologies with Zend OPcache v7.0.2-dev, Copyright (c) 1999-2013, by Zend Technologies with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans Web server: Nginx Test script: --- In php.ini: display_errors = Off display_startup_errors = Off Expected result: I expect no errors shown! Actual result: -- Errors shown... -- Edit bug report at https://bugs.php.net/bug.php?id=65099&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65099&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65099&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65099&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65099&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65099&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65099&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65099&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65099&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65099&r=support Expected behavior: https://bugs.php.net/fix.php?id=65099&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65099&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65099&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65099&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65099&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65099&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65099&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65099&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65099&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65099&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65099&r=mysqlcfg
