Bug 101003 - Assigning permissions 'appears' to fail if user has perm on parent object
Assigning permissions 'appears' to fail if user has perm on parent object
Status: CLOSED WONTFIX
Product: Red Hat Enterprise CMS
Classification: Retired
Component: other (Show other bugs)
nightly
All Linux
medium Severity medium
: ---
: ---
Assigned To: Archit Shah
Jon Orris
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-07-28 10:21 EDT by Daniel Berrange
Modified: 2007-04-18 12:56 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-02 13:41:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Berrange 2003-07-28 10:21:26 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.9 (X11; Linux i686; U;) Gecko/20030314

Description of problem:
When assigning permissions to objects, the forms 'appear' to silently fail if
the user is already inheriting the permission, either through the object context
hierarchy, or the privilege implications hierarchy.

For example:

  * Attempting to assign 'Administrator Account' as the admin for a role in CMS
'fails' because the SWA already has admin across the whole site. However, if you
assign the user as a role admin & then make them a SWA there are no problems.

  * Manipulating folder permissions. If the user already has 'create item'
privilege, then it is impossible to explicitly turn on 'edit item'. However, if
they are assigned in the other order (ie edit, then create) it works fine.

The problem appears to be that PermissionManager#grantPermission has the
following check:

    boolean hasPermission = checkPermission(universalPermission, isUser);
    if (hasPermission) {
        return true;
    }

The intent was obviously to avoid redundant privilege grants, but as the two
examples above illustrate, this is impossible & leads to very confusing user
interfaces / interactions. The check in in grantPermission should probably be
changed to only check for an exact match of the 'object,party,privilege'
triplet. ie ignore the object context & privilege implications heirarchies.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Go into the content section
2. Go to the roles tab
3. Add 'administrator account' as the role admin
    

Actual Results:  Nothing happens.

Expected Results:  The administrator is assigned as role admin.

Additional info:
Comment 1 David Lawrence 2006-07-17 22:54:21 EDT
QA_READY has been deprecated in favor of ON_QA. Please use ON_QA in the future.
Moving to ON_QA.
Comment 2 Daniel Berrange 2006-09-02 13:41:33 EDT
Closing old tickets

Note You need to log in before you can comment on or make changes to this bug.