Fix GH-20370: forbid user stream filters to violate typed property constraints

[alexandre-daubois]

Use zend_update_property() instead of doing things "manually".

[ndossche]

On a phone , so can't check. But you're looking at the property info now, however dynamic properties don't have any. So that means that a dynamically created property $stream would've been overwritten before this patch but now no longer. So that is an unintended behaviour change.

[alexandre-daubois]

Oh alright, I wasn't aware of this subtlety of dynamic properties. Let's refine that.

[bukka]

Hmm so that would require to someone create the dynamic property in filter first and it could then be used in subsequent calls for stream, right? If so, that sounds like a proper edge case... :)

[ndossche]

The easiest way to test this is to create a onCreate method that sets a dynamic property on $this

[ndossche]

This will work, except for a pre-existing bug:
When there is an unset or uninit typed property, but it is declared, its existence will be ignored.

It would also be great to try to avoid OBJPROP so that the property table isn't rebuilt, but that isn't critical.

[alexandre-daubois]

I tried to implement what you have in mind in 04e0955

[arnaud-lb]

The existing behavior skips magic methods and hooks, in addition to ignoring types and readonly. The updated code doesn't.

I think we should consider this an existing bug, so the update is fine.

In this case, we should also use obj->handlers->has_property() to check for property existence, and simplify to something like this:

	const zend_class_entry *old_scope = EG(fake_scope);
	EG(fake_scope) = Z_OBJCE_P(obj);

    zend_string *name = zend_string_init("stream", strlen("stream"));
	if (Z_OBJHANDLER_P(obj, has_property)(obj, name, ZEND_PROPERTY_EXISTS)) {
		zval stream_zval;
		php_stream_to_zval(stream, &stream_zval);
		zend_update_property_ex(Z_OBJCE_P(obj), Z_OBJ_P(obj), name, &stream_zval);
    }

    EG(fake_scope) = old_scope;

This way, we have less chances of diverging from normal behavior.

We should also check for exception after this.

[alexandre-daubois]

Thanks for the details! I tried to implement in 3d5358f

[arnaud-lb]

This needs to be changed as well, as setting a typed property to null may be incorrect. We should use Z_OBJHANDLER_P(obj, unset_property).

[arnaud-lb]

Is there a reason you could not use unset_property here?

[alexandre-daubois]

Did the updates iteratively and thought I could push not so long after the first one, but actually I'm struggling a bit to implement it here. Still on it 🙂

[alexandre-daubois]

Hmm, I wonder if it should be really used. It works on first call, then the property is fully uninitialized. Calling another stream operation breaks because of this (and many tests break when trying to implement it). The current approach "maintains" the property by just setting it to null. I guess we may keep it like this, unless I missed the point?

[arnaud-lb]

Ah ok, I was asking because you had marked this as resolved :)

Right, unsetting will not work. Thinking more about it, as the property was assigned with a resource above, it implies that the property has no type hint (or it's mixed). So we can simply assign null here, after all (with the same method as above).