Created attachment 952571 [details] patch for the "do_login" function. Description of problem: When using the 'spacecmd api_command' syntax (instead of simply using 'spacecmd' to open a command shell), if the user is not an organization administrator, and is trying to use the credential cache to perform multiple command line operations depending on that (eg: cat something | xargs -n 1 | spacecmd some_command ), spacecmd fails to use the credential cache. This happens because on the "do_login" function on /usr/lib/python2.6/site-packages/spacecmd/misc.py, while checking the active cached session key (stored on ~/.spacecmd/${hostname}/session), the function used is self.client.user.listUsers(self.session) This API call is not available for an user that is not at least an Org. Administrator, even if they have other roles attached to their account. This issue has been raised previously by David Juran (RedHat, I believe) on https://www.redhat.com/archives/spacewalk-list/2013-September/msg00086.html , but the patch submitted does not fix the issue completely, since the suggested API call always returns, even if the session key presented is not valid anymore, therefore an exception is not generated in case the session key has already expired. I proposed the attached patch be applied instead, that changes the validation function to satellite.listEntitlements(self.session), since this function: - does not require extra parameters but the session key - returns empty if the user is authorized, but has no authority to see them - raises an error if the user is calling it from an unauthorized or already-expired session. This does NOT affect the use-case where a user simply enters "spacecmd" and uses the spacecmd shell to perform actions, since the whole session uses the same in-memory credential cache, that doesn't use the problematic execution branch. Version-Release number of selected component (if applicable): spacecmd-1.9.4-1.el6.noarch How reproducible: Always reproducible, if performed with the credentials of an user that is not an Organization Administrator or above. Steps to Reproduce: As an user that is NOT set Organization Administrator or Satellite Administrator: 1. $ spacecmd login (fill the login information) 2. $ spacecmd system_list 3. $ spacecmd $another_spacecmd_command (these steps have to be performed in some succession, since there's a 30-or-so minutes for the session, after which the session key is invalid) Actual results: - The second command asks for the credentials again. Expected results: - The commands after the first 'spacecmd login' command should not ask for credentials, since they're cached (and still valid for that time) Additional info: Reference: https://www.redhat.com/archives/spacewalk-list/2013-September/msg00086.html Document URL: Section Number and Name: Describe the issue: Suggestions for improvement: Additional information: Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Please be aware that spacecmd is a community project and not supported by Red Hat for usage against Satellite. Also, we do plan though, in the future to support spacecmd, as part of the satellite 5.7 release. If this patch is valid, please, submit it to the Spacewalk community for review and acceptance (vs a Satellite bugzilla for something that is not supported within product currently). Please review: https://fedorahosted.org/spacewalk/wiki/Contribute Or send an email to spacewalk-devel mailing list. Regards, Cliff
This has been fixed in upstream back in 2013 ... (user.listAssignableRoles API is used for the mentioned purpose) spacewalk.git: 524dfd5bd855b90f174b57238bcca1df76b24fce The commit made it to Satellite 5.7 as well, so I am closing the BZ as CURRENTRELEASE.