Hello folks, ----- Original Message ----- > On 2013-10-21 02:42, Michael Mraka wrote: > > [email protected] wrote: > > % Should this be working? Am I missing a piece? Or are ISS slaves > > % really not able to see shared channels? > > > > In the Spacewalk 2.0 we enhanced ISS functionality to be able to > > serve different channel/package sets to different ISS slaves. > > ISS setup you've just described is possible, see detailed description > > and howto on > > https://fedorahosted.org/spacewalk/wiki/ISSSyncPermissions > > Michael, > > All of that is working, except that my slave cannot see *shared* > channels. Channels *owned* by the org which I export to the slave show > up in "satellite-sync --list-channels". However, channels which the org > does not own but has been granted access to from another org via trust > (shared channel) do not show up.
As one of the guys that implemented the new ISS-behavior, let me take a stab at why this is "working as intended". > To reproduce this: And a great reproducer it is, thanks - ISS is complicated, having specifics to talk to makes things much easier! > On master: > 1) Create a new channel "isstest" in your "Default" org > 2) Create a new org "SlaveOrg" > 3) Configure "Default" org to trust "SlaveOrg" > 4) Mark the "isstest" channel as "Protected", then grant the "SlaveOrg" > access to it > 5) Now, in ISS master setup, add IP/host for slave, only expose > "SlaveOrg" organization > > On Slave: > 1) Set up access to spacewalk master > 2) Run "satellite-sync --list-channels" The basic question being raised here is, should ISS limit channel-sync based on *ownership*, or *visibility*. The design came down on the side of "ownership". The main reason for that, is that in spite of how we all talk about it, ISS really is not a Master/Slave relationship, it's Peer-to-Peer. The "slave" can be maintained by its own admin, with its own set of orgs and permissions. Let's assume the code behaved as you're expecting it to - that is, channels are sync'd if they are visible, even though the owning org isn't. On the slave-side, to make 'isstest' visible to the SlaveOrg, one of two things would have to happen: 1) 'isstest' would be created as owned-by-default-org (regardless of which org owns it on the Master), and a trust relationship between the default-org and the slave-org in the ISS Slave would be created, or 2) 'isstest' would be created as owned-by the slave-org on the ISS Slave In case 1), the Slave ends up with a trust relationship that its admin may not have intended to allow. Now anyone in SlaveOrg can see any public channels owned by default-org, when before the sync they could not. In case 2), SlaveOrg has the visibility it had on the Master. However, it *also* now has edit-rights to the channel, which it did *not* have on the Master. Both of these situations are subtle changes to the slave's security setup, in ways the slave-admin may not expect. We felt this would be...rude. :) Also, related to "subtle" - allowing channels to be sync'd only if their owning-org is allowed, is a clearer security decision for the master-admin. If channels could be sync'd by visibility, then the master-admin has to think a lot more carefully about what orgs they want to allow, and what might be made visible 'downstream'. So, by design, ISS only allows syncing of channels that are *owned* by orgs that have been allowed by the master-admin. Grant _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
