We have parse_ini in our php.ini disabled_functions list because it was listed on the NSA Hardening Guidelines for our OS as a potential security issue. Can you explain to us what this module uses parse_ini for? Is it really necessary? There are other modules that rely on this module that we want to use, but can't if it requires opening up known "bad" functions. ie, Panels > CTools > Advanced Help

Here's the error:
parse_ini_file() has been disabled for security reasons in /var/www/domain/webroot/sites/all/modules/advanced_help/advanced_help.module on line 667.

Comments

merlinofchaos’s picture

merlinofchaos commented
Status: Active » Closed (works as designed)

Because $module.help.ini is a ini file and we need parse_ini_file() to parse it.

crimsondryad’s picture

crimsondryad commented

Yeah, I got that part. :P My question is does it really need to be an .ini file to begin with? Is there a benefit to making an .ini rather than a .inc or .php or .help? I understand that it's been that way for a long time. But looking around on the web, there seems to be a significant amount of debate over whether parse_ini_file is something that should be disabled. After all your hard work, wouldn't you want to share the love with as many Drupal sites as possible? Particularly if it was a fairly easy thing to do?

merlinofchaos’s picture

merlinofchaos commented

Well, given that it's been a .ini file for a long time and many modules are now using the format, it's not an easy change to make.

I did some research on the issue and I can't figure out *why* parse_ini_file() is on people's vulnerable lists. Every list I found simply lists it without explanation. After about 30 minutes of digging on various web pages, I gave up.

crimsondryad’s picture

crimsondryad commented

I did more checking on it as well. There seems to be a lot of "this is bad" without telling you *why* it's bad. According to php.net, the function can't be used to read php's ini file, just web script ini's. So not much of a security issue there. I believe we had ours in the disabled_functions list because php by default contains a sample string and parse_ini_file is in there. It's probably a holdover from safe_mode ::cringe::

I think people are getting confused about ini_set, ini_alter, and .htaccess overrides. Those can be *very* bad if abused, but almost everyone has them on.

Thanks bunches...sorry for bugging you about it. I'm going to leave this post out in case someone else comes across the same issue.

frob’s picture

frob
Primary language English
commented

Is there a reason that it doesn't use drupal's ini parsing function. That would let people with limited providers to use these modules and wouldn't change the user experience at all would it?

http://api.drupal.org/api/function/drupal_parse_info_file

merlinofchaos’s picture

merlinofchaos commented

Yes, Drupal's ini parsing function handles sections differently. While more powerful, the syntax is less useful for this purpose.

frob’s picture

frob
Primary language English
commented

Just came across this and thought I would through it out there.

AdrianB’s picture

AdrianB commented

So, since this is "works as designed", has anyone solved/worked around the "parse_ini_file() has been disabled for security reasons in" errors?

Other than disabling this modules, of course. I have a site where they started to pop up recently (don't know why, probably the host did some changes to the server).