Bug 1368397

Summary: spacecmd should generate caches for the server+user combination
Product: Red Hat Satellite 5 Reporter: Fabien Malfoy <keldrill>
Component: UsabilityAssignee: Eric Herget <eherget>
Status: CLOSED CURRENTRELEASE QA Contact: Lukáš Hellebrandt <lhellebr>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 570CC: eherget, lhellebr, tkasparek, tlestach
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: spacecmd-2.6.15-1 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-06-21 12:11:24 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1358815    

Description Fabien Malfoy 2016-08-19 09:34:19 UTC
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...>

Comment 1 Tomas Lestach 2016-08-19 09:44:55 UTC
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.

Comment 3 Eric Herget 2016-09-28 20:14:48 UTC
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

Comment 5 Lukáš Hellebrandt 2017-02-28 10:02:06 UTC
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.