This issue needs to be addressed in the selinux-policy. 

We can either overload an existing boolean:

tunable_policy(`rsync_full_access',`
        allow rsync_t self:capability {  dac_read_search };
        files_manage_non_auth_files(rsync_t)
')

or create a new one. Is it possible the extended attributes from the trusted namespace need to be accessed by other services than rsync?

(In reply to Zdenek Pytela from comment #4)
> This issue needs to be addressed in the selinux-policy. 
> 
> We can either overload an existing boolean:
> 
> tunable_policy(`rsync_full_access',`
>         allow rsync_t self:capability {  dac_read_search };
>         files_manage_non_auth_files(rsync_t)
> ')
> 
 
 Can this change be done in the glusterfs-selinux package itself? If i understand it correctly, we are already adding an interface for rsync in the glusterd.if file, could this rule be added in the glusterd.te or should the change be made explicitly in the rsync.te

> or create a new one. Is it possible the extended attributes from the trusted
> namespace need to be accessed by other services than rsync?

 We are checking if tarssh also faces the said issue. The geo-replication basically has two modes, one using rsync as the sync engine and the other wherein we use tarssh as the sync engine.

(In reply to Srijan Sivakumar from comment #5)
> (In reply to Zdenek Pytela from comment #4)
> > This issue needs to be addressed in the selinux-policy. 
> > 
> > We can either overload an existing boolean:
> > 
> > tunable_policy(`rsync_full_access',`
> >         allow rsync_t self:capability {  dac_read_search };
> >         files_manage_non_auth_files(rsync_t)
> > ')
> > 
>  
>  Can this change be done in the glusterfs-selinux package itself? If i
> understand it correctly, we are already adding an interface for rsync in the
> glusterd.if file, could this rule be added in the glusterd.te or should the
> change be made explicitly in the rsync.te
What I propose is to make the change in selinux-policy: with this or another boolean, giving too many privileges, not turned on by default, so with a subsequent need to handle it in the gluster (or related) rpm scriptlet.

> 
> > or create a new one. Is it possible the extended attributes from the trusted
> > namespace need to be accessed by other services than rsync?
> 
>  We are checking if tarssh also faces the said issue. The geo-replication
> basically has two modes, one using rsync as the sync engine and the other
> wherein we use tarssh as the sync engine.
Thank you, based on the results we get to the final resolution. I will also include further steps to follow if required.

We target RHEL 8.4 for resolving this issue in the selinux-policy package. Currently we are awaiting the information if the same capability is required for another service.

As a temporary solution, I created a PR to address the issue directly in glusterfs:
https://github.com/gluster/glusterfs-selinux/pull/9

This commit can be reverted once the permission is in RHEL.

(In reply to Zdenek Pytela from comment #9)
> We target RHEL 8.4 for resolving this issue in the selinux-policy package.
> Currently we are awaiting the information if the same capability is required
> for another service.
> 
> As a temporary solution, I created a PR to address the issue directly in
> glusterfs:
> https://github.com/gluster/glusterfs-selinux/pull/9
> 
> This commit can be reverted once the permission is in RHEL.

Hello Zdenek,

Requesting to include this fix in RHEL 8.3.z, as the RHGS feature is
completely broken without workaround, for those customers that are using
previous version of RHGS consumed by RHVH 4.4.2.

glusterfs-selinux package that gets shipped with RHGS 3.5.3, will address
the issue for new customers.

Can you help to target this bug to RHEL 8.3.z ?

The fix needs to be delivered to RHEL 8.4 first before requesting z-stream clone.

Srijan, in c#5 you mentioned another mode. Have you or anybody else from your team managed to find out if there are some denials in this mode, too?

 Hi Zdenek. Yes geo-replication uses two different sync engines
  1. tarssh
  2. rsync

 tarssh is the mode which we haven't pursued much into in terms of the denials. I'll try to collect data on tarssh and communicate the same here.

 Regards,
 Srijan

 Hi Zdenek,

 I checked with my team member who had checked for tarssh. Now the observation is that after using the updated glusterfs-selinux rpm, tarssh is not throwing any errors. It is working as expected.

 Tarssh is the other service which I was talking about earlier.

 Regards,
 Srijan

I've submitted a Fedora PR to address the issue:
https://github.com/fedora-selinux/selinux-policy/pull/530

The suggested boolean name is rsync_sys_admin.

PR merged:
commit 46d834991b9d07400b9feb8aee2d85e40cfe95d7 (HEAD -> rawhide, upstream/rawhide)
Author: Zdenek Pytela <zpytela>
Date:   Tue Jan 5 20:02:19 2021 +0100

    Add rsync_sys_admin tunable to allow rsync sys_admin capability

    The rsync_sys_admin tunable was added to allow rsync the sys_admin
    capability conditionally. This permission is required for rsync to
    be able to restore files with extended attributes in all attributes
    namespaces. Glusterfs makes use of the "trusted" namespace for which
    the sys_admin capability is required.
    The boolean is off by default.

    Resolves: rhbz#1889673

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (selinux-policy bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:1639