Privilege Escalation: Long history of field access breaking non-OG content

This a long-standing issue with many similar reports of different scenarios. I found it in issue tracker history via Google after encountering it myself. My case required a non-OG module misbehavior to reveal the symptoms.

Issue Severity

I've marked this "critical" on the dev branch for a few reasons. We need someone very familiar with OG internals to review the reports of this (which I'll attempt to compile and summarize a bit, here).

The bug causes a form a privilege escalation, where group roles with permission to edit in-group permissions can now influence site-wide behavior, including field access on user profiles.

I have not fully investigated whether or not this privilege escalation can be exploited to allow malicious users to modify fields on other user accounts. I did test an obvious case through forms, and did not get the user profile field to print on-page. However, I haven't tried POST request modification, for instance.

This bug affects a clean Drupal installation. The effects can prevent very basic and expected uses of Drupal, and will do this quietly and without issuing obvious symptoms, including no error messages being generated.

The issue has been addressed before in 7.x-1.x, thought to be fixed, and closed. It's not fixed. There appears to be some work-arounds, though.

Bug Behavior

Fields added to the user entity are pulled into OG field access controls. A field is added to admin/config/group/permissions/node/group_name at the moment that the field is created in admin/config/people/accounts/fields. This defaults the field to have no permission grants within OG. The field access control will be given to all groups within the site. Everywhere the field is referenced, OG grants will be in the list of permissions to be checked.

User entity is a group content type within OG, but isn't provided with any OG configuration interface by default.

In my system I have:

• A custom field on users added through admin/config/people/accounts/fields
• This field is required, and enforced by Complete Profile
• Groups made and available to users at registration (a core feature of the site)
• All group context detection methods turned on, except "Group url"
• Edit profile module, which fully revealed this bug to me

This sets up a scenario where the user is forced to enter a field value that they will not be able to edit later, even though they are intended to be able to. If they typo on data entry at registration, they will require admin intervention where that is unintended.

Site and group admins will probably not know that this is happening, because their own user accounts will usually have the needed field access permission granted to them by default.

Group permissions in all of a site's groups influence this behavior. If edit permission is given to non-member and member, the field becomes editable on all user profile pages. The inverse is also true: if the edit permission is not granted, or the user is not joined to any group that grants it, then the field is visible but not editable on the user's own profile. This escalates the permissions of the group members to potentially risky levels.

Work Around

User entity can be made into a group, by adding the "Group" field to the "User" bundle in admin/config/group/fields.

The "Group" field value must then be set to true for all existing user accounts. Having done this, every user will gain access to those custom fields. The user is automatically granted ownership of their account group. New accounts are also automatically granted ownership of their account group.

Shortcomings of Work Around

In my system, a role with "Administer users" permission is unable to modify the custom fields on user entities. Only the account owner or site administrator (UID 1) is able to do this. It is OG field access again causing this. Assistant-admins with less than UID 1 permissions would need to be made members of every account's group, to work around this.

History

The following is highlights of page 1 of 3 for an issues search on "field access" in 7.x series. Nearly all of these have aged without follow-up. I've summarized them above, referenced them here, and am marking them duplicates and dropping a reference to this report in each of them.

#1029230: Og context + og field access make fields disappear for non-group nodes. points to OG Context and OG Field Access being the culprits. This was closed after code changes in 7.x-1.x-dev.

#1578648: When OG access control is enabled, node_access checks are added to user entity queries shows the SQL related to this issue.

#1916966: User entity custom fields access calls out this issue specifically, but as a normal priority support request. Includes some code.

#1491510: Non-admin users can't access added fields shows this issue, including the user edit page $form array in admin and non-admin scenarios.

#1477678: Permission mismatch if the same field is used for nodes and users discusses some details surrounding this issue.

#1138150: Problem with field access could be related.