Description of problem: As of the current RHS 5.7 version of spacecmd (spacecmd-2.3.0-4.el6sat.noarch), the command generates a set of caches (errata, packages, systems...) for each different server to which one connects. However, errata list, packages list or even systems list also strongly depends on the user (and therefore the organization) to which the session belongs. Current behaviour of caches prevents different users to access their specific informations without clearing the caches prior to any action when connecting to the same server but in different organizations. Solving this problem may also enhance the way spacecmd allows concurrent use. Version-Release number of selected component (if applicable): spacecmd-2.3.0-4.el6sat.noarch How reproducible: Have two organizations with specific sets of elements (systems, errata, packages...) Steps to Reproduce: On a satellite satX : 1. Create two organizations orgA and orgB with respective organization administrators adminA and adminB 2. Create a system profile sysA in orgA and another one sysB in orgB Connected as a userX on a station desktopX : 3. Use spacecmd to connect to satX as adminA 4. Issue a system_list --> will generate the systems cache for satX and actually show the systems from orgA 5. Diconnect from adminA@satX 6. Use spacecmd to connect to satX as adminB 7. Issue a system_list --> will NOT generate the systems cache for satX since it already exists locally and will actually show the systems from orgA instead of orgB Actual results: adminB sees the systems from orgA instead of orgB unless caches are cleared. Expected results: adminB sees the systems from orgB without clearing any cache and no matter the fact another organization's user connected to the same server previously. Additional info: adminB should have his own cache separate from the one of adminA on satX As a suggestion, spacecmd could manage cache files in a tree like the following : ~/.spacecmd |-- config |-- history |-- <serverX> | |-- session | |-- <userA> | | |-- errata | | |-- systems | | |-- packages_short | | +-- <cache...> | |-- <userB> | +-- <user...> |-- <serverY> | |-- session | |-- <userA> | |-- <userB> | +-- <user...> +-- <server...>
I'm not sure if we want to redesign the spacecmd cache, but if adminB sees the systems from orgA, we need to clear the cache at least.
Turns out the fix to modify the cache file paths as described in the original description required changing just 3 lines of code, so that is the solution I implemented. spacewalk.github: 3408aa56d087d474113e03faae679a62900fa863
Note that from security point of view, this did not fix anything - as the caches are local, another user can still access them albeit not through spacecmd anymore. This, however, does not seem to be a problem - as spacecmd stores its cache in the calling OS's user's home directory, this is a problem of local machine's security and probably bad OS's account usage. I can verify that the caches are now separate for different users and users see correct data for their organization through spacecmd. Verified with spacecmd-2.5.0-7 from Sat 5.8 compose from 2017-02-26.