When Ibexa user has a content/edit policy with FieldGroup limitation, they should only be able to edit a subset of field groups while other field groups should be in read-only mode.

This form rendering logic is broken when the content being edited is a user (has a User field type anywhere in it). Fields, which the user should have no permission to update, get rendered as regular fields (inviting to update their values).

It's probably not a security issue because Ibexa is still able to catch an attempt to update a field belonging to a field group that is outside of one's policies/access, but it fails with a crash (exception thrown).

We've investigated a bit and it turns out that the mere presence of User field type makes Ibexa to use a different set of PHP classes for handling all the form fields. It seems that these classes operate on different sets of structs. Separating these sets of classes completely probably helped for the non-integrity to go unnoticed.

Steps to reproduce:

(1) Create a new content type like "DummyUser". In that content type, put the following field group and field structure:

General:

• First name [text line]
• Last name [text line]

User account:

• User [user]
• Description [text block]

Details:

• Age [integer]
• Address [text line]

(2) Create a Tester role which will allow user to log into Ibexa admin, navigate content plus include the following policies:

• Content/Create - ContentType: DummyUser;
• Content/Edit - ContentType: DummyUser; FieldGroup: General, User account;
• Content/Publish - ContentType: DummyUser;

Create a Tester user account with this new Tester role assigned.

(3) Still as an admin, create one content/user based on DummyUser content type.

(4) Relogin as Tester user and edit this newly created DummyUser content.

Despite having no access to "Details" field group, fields "Age" and "Address" will render as regular fields, accepting values.

However, if you update these fields and try to publish DummyUser content, it should crash.