On database level Red Hat channels have channel_access field set to null and it's not possible to set any value for them and it doesn't make any sense either. This is only displaying bug. It's low prio bug for me.

What it should display instead?

channels synced on 5.7 has private channel_access

# select label, channel_access from rhnchannel where label like 'rhel-%';
               label               | channel_access 
-----------------------------------+----------------
 rhel-x86_64-server-6.4.z          | private
 rhel-x86_64-server-6.6.z          | private
 rhel-s390x-server-6               | private
 rhel-x86_64-server-sfs-6          | private
 rhel-x86_64-server-6-rhscl-1      | private
 rhel-x86_64-hpc-node-7            | private
....


but cnd-sync on 5.8 sets it to null

# select label, channel_access from rhnchannel where label like 'rhel-%';
            label            | channel_access 
-----------------------------+----------------
 rhel-s390x-server-6         | 
 rhel-s390x-server-5         | 
 rhel-x86_64-server-6        | 
 rhel-x86_64-server-7        | 
 rhel-x86_64-server-extras-7 | 
 rhel-x86_64-server-5        | 


(tested on upgraded 5.7 to 5.8)
spacecmd {SSM:0}> softwarechannel_getorgaccesstree rhel-s390x-server-6
rhel-s390x-server-6 : private

# cdn-sync -c rhel-s390x-server-6 --no-packages --no-errata --no-kickstarts 

spacecmd {SSM:0}> softwarechannel_getorgaccesstree rhel-s390x-server-6
ERROR: no element found: line 1, column 0


if channel_access makes no sense for RH channels it could show nothing or null..

Interesting, I'm thinking about fixing it in cdn-sync by setting private for each channel. I'm not sure if it has any purpose for Red Hat channels but it's probably better to set it to keep same behavior and prevent this bug and possibly others.

from backend/satellite_tools/xmlSource.py:

# if importing from an old export that does not know about
# channel_access, use the default
if not obj['channel_access']:
    obj['channel_access'] = 'private'

satellite-sync is setting this to private if it's not defined

fixed in spacewalk master:

f1b12888ce465c420e1f018c4aa6c785901937c6

I can verify the command now works correctly.

However, I have doubts about semantic meaning of setting Red Hat channels to private. I believe almost the opposite is true - these are accessible by any organization with enough entitlements while "private" suggests they are only accessible by the organization they are in. To stay on the safe side, it might be wiser to show more possible access rights than less. (If you decide to change this, however, be careful to check if the value is used somewhere for Red Hat channels.)

I understand this is because we didn't want to change the behavior of older versions. Yet, I still want some confirmation this is indeed what we want to do.

fixed in spacewalk-java package, the current behavior is to return permission error for null org channels, same as for other channels user can't manage

This solution seems to be fine, generally.

However, when calling "softwarechannel_getorgaccesstree" without arguments, permissions of all the channels are attempted to be listed, including RH channels which leads to "ERROR: redstone.xmlrpc.XmlRpcFault: You do not have permissions to perform this action.".

It should be enough not to attempt to list RH channels in this case.

Wouldn't be just easier to skip printing any channels which returned XmlRpcFault - print only valid lines? The patch is simple. Skipping RH channels doesn't fix anything because the same can happen for custom channels too if user can subscribe to channel but can't manage it. And fixing this doesn't seem trivial because spacecmd is not ready to distinguish between custom/Red Hat/managable channels.

Finally, I needed to add channel.listManageableChannels API to list only channels which is user permitted to manage - and access org sharing settings. Then I added softwarechannel_listmanageablechannels function to spacecmd and updated softwarechannel_*orgaccess* to work with output of manageable channels only.

spacewalk master:

6030113aa3ab3066d0ef6636ecdbfd0302ed8bdd
015084ae6b7ce7c0550e1197e07388886f90caab
aa979ed31135e1b943adef0e8e03be75756ac48f
76c7404add2ee64c15830d2da5aabe0b896df05e

Specifying some existing but nonmanageable channel to these calls does not trigger any error and is just silently ignored:

# softwarechannel_getorgaccesstree rhel-x86_64-server-6

# softwarechannel_getorgaccess rhel-x86_64-server-6

For comparison, this happens in case of nonexistent channel:

# softwarechannel_getorgaccesstree nonexistentchannel
ERROR: Channel does not exist or is not a base channel!
softwarechannel_getorgaccesstree: Get the org-access for a software base channel and its children
usage: softwarechannel_getorgaccesstree [CHANNEL]

# softwarechannel_getorgaccess nonexistentchannel

I think both is wrong. The case of nonexistent channels is, however, not related to this bug. Do we want to make this behavior consistent (*tree call for nonmanageable channel throws exception while non-*tree call does not, as in case of nonexistent channel), make it correct (both throw [different than nonexistent channel] exception in case of nonmanageable channel) or leave it as it is (because we've given this issue too much time already, given its importance)?

It could be better but I think the required effort is out of scope of this bug. It would require comparing results of multiple API calls to evaluate which channels are subscribeable, which are manageable and which are non-existent, in different org etc. There also exceptions like the *tree call can take the non-managable channel because some of it's childs can be manageable. Also note, this is the first spacecmd function actually checking some channel is manageable or not, I expect there are more functions in spacecmd which should have this check too but this has a low priority now.

I agree. Verified with spacecmd-2.5.0-13.

- RH channels are now not listed or modifiable by these spacecmd commands at all.
- Even trying to bypass spacecmd and using API directly doesn't allow user to manipulate these channels.
- The new API call channel.listManageableChannels lists (only) expected channels.

- There are minor inconsistenses or weird behavior when using these calls on nonexistent or nonmanageable channel. We concluded this is out of scope of this bug and not worth the effort at all.

*** Bug 997414 has been marked as a duplicate of this bug. ***