# Big thanks! **URL:** \ **Category:** Ideas and Feature Requests\ **Created:** [August 12, 2016, 1:53pm UTC](https://forum.mautic.org/t/big-thanks/4866 "2016-08-12T13:53:48Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![escopecz](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/escopecz/32/370_2.png) [@escopecz](https://forum.mautic.org/u/escopecz)\ **Post date:** [August 12, 2016, 1:53pm UTC](https://forum.mautic.org/t/big-thanks/4866/1 "2016-08-12T13:53:48Z")
Hi, this is the first time I start a personal conversation ![:)]( ":)") I just wanted to thank you for your calm and brilliant explanation of the “security issue”. David removed the thread as a flame war. If you’d want to place your answer elsewhere, on a github issue like [https://github.com/mautic/mautic/issues/2034](https://github.com/mautic/mautic/issues/2034) perhaps, I saved it for you: Quote: Well, thanks for confirming what I thought in the first place but I didn't have any proof. Your tech support admin is clueless as well. One of the first things you do in securing a PHP installation is to setup open\_basedir especially when using vhosts. That's not my recommendation, that's from well-known security practices documented not only internet wide, but on PHP's secure practices site as well. You, like most people, hosters include, don't know about or use open\_basedir as an added measure to secure PHP installs because it's commented out by default in php.ini. Having open\_basedir empty is essentially the same as the commented out default. Your PHP has no restrictions filesystem wide where the user your web server runs under has read access, at a minimum, and has write access to any world writeable file and directory or group writeable file and directory. ![image.png](https://s10.postimg.org/8c3x34r0p/image.png) It's one of the principle means of preventing any XSS or rogue PHP vulnerability causing damage systemwide. Don't take my word for it, here's an explanation on PHP's site what it's supposed to prevent (https://secure.php.net/manual/en/ini.core.php#ini.open-basedir) or just look in the image above. Open\_basedir is a poorman's "jail". However, this supposed vulnerability doesn't work the way you think it does. If you don't know what a random generator is or what it does relating to this by accessing the entropy pool in urandom generated by devices drives simply running in kernel space, it's best to remain quiet. The discussion explains how the v2 version ignores the random generator in OpenSSL and uses the random generator from Linux's kernel space (/dev/urandom) instead. With a correctly locked down open\_basedir restricted only to where PHP files reside, PHP rightly blocks access outside access except for the directories whitelisted which is good practices. ---
**Author:** ![escopecz](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/escopecz/32/370_2.png) [@escopecz](https://forum.mautic.org/u/escopecz)\ **Post date:** [August 12, 2016, 1:53pm UTC](https://forum.mautic.org/t/big-thanks/4866/2 "2016-08-12T13:53:48Z")
Hi, this is the first time I start a personal conversation 🙂 I just wanted to thank you for your calm and brilliant explanation of the “security issue”. David removed the thread as a flame war. If you’d want to place your answer elsewhere, on a github issue like [https://github.com/mautic/mautic/issues/2034](https://github.com/mautic/mautic/issues/2034) perhaps, I saved it for you: [quote]Well, thanks for confirming what I thought in the first place but I didn’t have any proof. Your tech support admin is clueless as well. One of the first things you do in securing a PHP installation is to setup open\_basedir especially when using vhosts. That’s not my recommendation, that’s from well-known security practices documented not only internet wide, but on PHP’s secure practices site as well. You, like most people, hosters include, don’t know about or use open\_basedir as an added measure to secure PHP installs because it’s commented out by default in php.ini. Having open\_basedir empty is essentially the same as the commented out default. Your PHP has no restrictions filesystem wide where the user your web server runs under has read access, at a minimum, and has write access to any world writeable file and directory or group writeable file and directory. ![](https://s10.postimg.org/8c3x34r0p/image.png) It’s one of the principle means of preventing any XSS or rogue PHP vulnerability causing damage systemwide. Don’t take my word for it, here’s an explanation on PHP’s site what it’s supposed to prevent ([https://secure.php.net/manual/en/ini.core.php#ini.open-basedir](https://secure.php.net/manual/en/ini.core.php#ini.open-basedir)) or just look in the image above. Open\_basedir is a poorman’s “jail”. However, this supposed vulnerability doesn’t work the way you think it does. If you don’t know what a random generator is or what it does relating to this by accessing the entropy pool in urandom generated by devices drives simply running in kernel space, it’s best to remain quiet. The discussion explains how the v2 version ignores the random generator in OpenSSL and uses the random generator from Linux’s kernel space (/dev/urandom) instead. With a correctly locked down open\_basedir restricted only to where PHP files reside, PHP rightly blocks access outside access except for the directories whitelisted which is good practices. [/quote]