Skip to content

Audit zend_ini_string() and related functions#21146

Open
Girgias wants to merge 13 commits intophp:masterfrom
Girgias:ini-audit-zend_ini_string
Open

Audit zend_ini_string() and related functions#21146
Girgias wants to merge 13 commits intophp:masterfrom
Girgias:ini-audit-zend_ini_string

Conversation

@Girgias
Copy link
Member

@Girgias Girgias commented Feb 6, 2026

Conflicts with #21143

I audited the usage of zend_ini_string() and co as I believe these functions should return a const char* because they point to a pointer owner by a zend_string *.

The two other things I am wondering is

  • if we should remove the INI_STR() macro as it doesn't follow the usual convention of "string" being a char* and "str" meaning a zend_string*.
  • if we should remove the INI_ORIG_* macros as they seem mostly pointless?

Copy link
Member

@arnaud-lb arnaud-lb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

One caveat with ZEND_STRL() is that it would break if the outer function call was turned into a macro, as it is seen as a single argument during expansion.

An alternative to removing INI_STR(), that would also eliminate the need for ZEND_STRL(), would be to introduce _literal variants of zend_ini_str(ing)(_ex), like we have in the string API, and then remove or deprecate INI_STR(). But then we might want to also add _literal variants of the other zend_ini_ functions to replace all INI_ macros. No strong opinion on this.

@Girgias
Copy link
Member Author

Girgias commented Feb 17, 2026

Looks good to me.

One caveat with ZEND_STRL() is that it would break if the outer function call was turned into a macro, as it is seen as a single argument during expansion.

An alternative to removing INI_STR(), that would also eliminate the need for ZEND_STRL(), would be to introduce _literal variants of zend_ini_str(ing)(_ex), like we have in the string API, and then remove or deprecate INI_STR(). But then we might want to also add _literal variants of the other zend_ini_ functions to replace all INI_ macros. No strong opinion on this.

I quite like the idea of using a new literal API variant, will do this and check what the usage of thoses macros are with sourcegraph to see if it is reasonable to remove them outright or not.

if (cafile == NULL) {
cafile = zend_ini_string("openssl.cafile", sizeof("openssl.cafile")-1, 0);
cafile = strlen(cafile) ? cafile : NULL;
const zend_string *cafile_str = zend_ini_str_literal("openssl.cafile");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel this should be zend_ini_string_literal, since you don't actually use the stored length for further processing (i.e. OpenSSL takes a NUL-terminated C string).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issue is that this leads to calling to zend_ini_str which returns an empty string if the INI setting exists, but the current code does the strlen() check to determine if it is an empty string or not and sets it back to NULL if so. And I don't want to change the behaviour of now sometimes passing an empty string to openssl.

if (capath == NULL) {
capath = zend_ini_string("openssl.capath", sizeof("openssl.capath")-1, 0);
capath = strlen(capath) ? capath : NULL;
const zend_string *capath_str = zend_ini_str_literal("openssl.capath");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto

char *extension_dir;

extension_dir = INI_STR("extension_dir");
zend_string *extension_dir = zend_ini_str_literal("extension_dir");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly this one is used as a C string.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, but the length of it is recomputed using strlen() so I don't see why we wouldn't just use the known information directly?

Moreover, we could potentially remove the calls to spprintf() and just use the string concat API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants