[Spacewalk-list] ISS: Slave cannot see shared channels

[Grant Gainey]

Hello folks,

----- Original Message -----
> On 2013-10-21 02:42, Michael Mraka wrote:
> > sam at eventbase.net 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