The user_access function in the user.module should look up the access rights of the currently logged in user, or if an alternative user is given, that user.

In order to ensure that the administrative user always has access rights, this is checked in the beginning of this function. However, this check is made for the current user. This doesn't make sense if the call to this function is asking about another user.

The attached patch makes it check the administrative user, but for the user requested, or if no user is requested the currently logged in one.

CommentFileSizeAuthor
user.module.patch1584 bytesAlanChandler

Comments

TDobes’s picture

TDobes commented

+1 on this. Straightforward fix for an annoying problem.

Steven’s picture

Steven commented

Fixed in HEAD/4.5.

Anonymous’s picture

(not verified) commented
TDobes’s picture

TDobes commented

Something went wrong when this patch was applied to CVS.
Take a look at the change that was applied as opposed to the supplied patch.

The if statement which grants all rights to uid=1 should be based upon account->uid, not $user-> uid. This part of the patch did not land. Therefore, this is still broken, as described in the original problem report. This can be seen by going to the user page for a user without the "edit own blog" permission while logged in as uid=1... the "view recent blog entries" will still appear even though they have not been granted the appropriate permission.

Bug exists in 4.5 and HEAD branch.

dries’s picture

dries commented

Corrected in both HEAD and DRUPAL-4-5. Thanks.

Anonymous’s picture

(not verified) commented