Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1136492 - activationkey.listActivationKeys API does not restrict results based on user privileges
Summary: activationkey.listActivationKeys API does not restrict results based on user ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Spacewalk
Classification: Community
Component: API
Version: 2.2
Hardware: All
OS: All
medium
medium
Target Milestone: ---
Assignee: Jan Dobes
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: space23
TreeView+ depends on / blocked
 
Reported: 2014-09-02 17:24 UTC by Tasos Papaioannou
Modified: 2015-04-14 19:03 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1136491
Environment:
Last Closed: 2015-04-14 19:03:12 UTC
Embargoed:


Attachments (Terms of Use)

Description Tasos Papaioannou 2014-09-02 17:24:58 UTC
+++ This bug was initially created as a clone of Bug #1136491 +++

Description of problem:

According to the API guide:

https://satellite.example.com/rhn/apidoc/handlers/ActivationKeyHandler.jsp#listActivationKeys

Method: listActivationKeys
Description:
List activation keys that are visible to the user.

The API, however, returns all activation keys in the user's organization, regardless of whether the user has the necessary admin privileges to view them. If a normal user (no admin roles), for example, runs this API, then all activation keys in the user's org will be returned. Calling activationkey.getDetails on one of those activation keys will return an error, because getDetails does restrict the results based on user roles.

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

spacewalk-java-2.0.2-79.el6sat.noarch

How reproducible:

100%

Steps to Reproduce:
1.) As an Org Admin or Activation Key Admin, create an activation key.
2.) Create a normal user, with no admin privileges.
3.) Verify that activationkey.listActivationKeys incorrectly returns the activation key for this normal user.

# spacewalk-api --user normaluser --password XXX --server=localhost activationkey.listActivationKeys "%session%"

$result = [
            {
[...]
              'description' => 'test-key',
              'key' => '1-test-key',
[...]

4.) Verify that activation.getDetails, on the other hand, correctly restricts the user from viewing the activation key:

# spacewalk-api --user normaluser --password XXX --server=localhost activationkey.getDetails "%session%" "1-test-key"
Fault returned from XML RPC Server, fault code -1: redstone.xmlrpc.XmlRpcFault: unhandled internal exception: Could not find activation key: 1-test-key


Actual results:

The activationkey.listActivationKeys API does not check user privileges.


Expected results:

The activationkey.listActivationKeys API should check user privileges based on user privileges.

Additional info:

The code responsible is:

****
./java/code/src/com/redhat/rhn/frontend/xmlrpc/activationkey/ActivationKeyHandler.java:

    public List<ActivationKey> listActivationKeys(User loggedInUser) {
        List<ActivationKey> result = new ArrayList<ActivationKey>();
        ActivationKeyManager manager = ActivationKeyManager.getInstance();
        for (Iterator it = manager.findAll(loggedInUser).iterator(); it.hasNext();) {
            ActivationKey key = (ActivationKey)it.next();
            result.add(key);
        }

        return result;
    }

./java/code/src/com/redhat/rhn/manager/token/ActivationKeyManager.java:

    public List <ActivationKey> findAll(User requester) {
        Session session = null;
        session = HibernateFactory.getSession();
        return session.getNamedQuery("ActivationKey.findByOrg")
           .setEntity("org", requester.getOrg())
           .list();
    }

./java/code/src/com/redhat/rhn/domain/token/ActivationKey.hbm.xml:

    <query name="ActivationKey.findByOrg">
        <![CDATA[from com.redhat.rhn.domain.token.ActivationKey as ak where ak.token.org = :org and ak.kickstartSession = null and ak.token.server = null]]>
    </query>
****

So, the list of activation keys is restricted only to those in the user's organization, but there is no check on whether the user actually has the ability to view them. Compare this to activationkey.getDetails, which does restrict based on user privileges, using the validateCredentials function:

****
./java/code/src/com/redhat/rhn/frontend/xmlrpc/activationkey/ActivationKeyHandler.java:

    public ActivationKey getDetails(User loggedInUser, String key) {
        ActivationKey aKey = lookupKey(key, loggedInUser);
        return aKey;
    }

    private ActivationKey lookupKey(String key, User user) {
        return XmlRpcActivationKeysHelper.getInstance().lookupKey(user, key);
    }

./java/code/src/com/redhat/rhn/frontend/xmlrpc/activationkey/XmlRpcActivationKeysHelper.java:

    public ActivationKey lookupKey(User user, String key) {
        ActivationKeyManager manager = ActivationKeyManager.getInstance();
        ActivationKey activationKey = manager.lookupByKey(key, user);
        if (activationKey == null) {
            String msg = "Activation Key [" + key + "] Not Found!";
            throw new FaultException(-212, "ActivationKeyNotFound", msg);
        }
        return activationKey;
    }

./java/code/src/com/redhat/rhn/manager/token/ActivationKeyManager.java:

    public ActivationKey lookupByKey(String key, User user) {
        ActivationKey ac = ActivationKeyFactory.lookupByKey(key);
        validateCredentials(user, key, ac);
        return ac;
    }

    public void validateCredentials(User user, String keyStr, ActivationKey key) {
        if (!canAdministerKeys(user, key)) {
            LocalizationService ls = LocalizationService.getInstance();
            LookupException e;
            if (keyStr != null) {
                e = new LookupException("Could not find activation key: " +
                        keyStr);
            }
            else {
                e = new LookupException("Could not find activation key");
            }

            e.setLocalizedTitle(ls.getMessage("lookup.activationkey.title"));
            e.setLocalizedReason1(ls.getMessage("lookup.activationkey.reason1"));
            e.setLocalizedReason2(ls.getMessage("lookup.activationkey.reason2"));
            throw e;
        }
    }

    private boolean canAdministerKeys(User user, ActivationKey key) {
        return user != null && key != null &&
                 user.getOrg().equals(key.getOrg()) &&
                    user.hasRole(RoleFactory.ACTIVATION_KEY_ADMIN);
    }
****

Comment 1 Jan Dobes 2014-10-01 12:44:33 UTC
fixed in spacewalk master:

74b9148ebb85c2cd54a26558412f0007f9c33d89

Comment 2 Grant Gainey 2015-03-23 16:59:05 UTC
Moving bugs to ON_QA as we move to release Spacewalk 2.3

Comment 3 Grant Gainey 2015-04-14 19:03:12 UTC
Spacewalk 2.3 has been released. See

https://fedorahosted.org/spacewalk/wiki/ReleaseNotes23


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