Bug 1889673 - [RHEL 8] Geo-replication in rsync mode is fails to sync data to the secondary sharded gluster volume
Summary: [RHEL 8] Geo-replication in rsync mode is fails to sync data to the secondary...
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: selinux-policy
Version: 8.2
Hardware: Unspecified
OS: Linux
high
urgent
Target Milestone: rc
: 8.3
Assignee: Zdenek Pytela
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks: 1874049
TreeView+ depends on / blocked
 
Reported: 2020-10-20 11:03 UTC by Srijan Sivakumar
Modified: 2020-11-26 04:05 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)

Description Srijan Sivakumar 2020-10-20 11:03:38 UTC
Description of problem: The geo-replication in RHGS fails due to rsync not being able to read the xattrs using getxattr syscall.

Version-Release number of selected component (if applicable):


How reproducible: Every time.

Steps to Reproduce:
1. Create a GlusterFS primary and secondary volume.
2. Start geo-rep session between them.
3. Syncing should fail and the audit logs will contain AVC denials for rsync.

Actual results:

AVC Logs : 
type=AVC msg=audit(1603177114.816:1686): avc: denied { sys_admin } for pid=36464 comm="rsync" capability=21 scontext=system_u:system_r:rsync_t:s0 tcontext=system_u:system_r:rsync_t:s0 tclass=capability permissive=0 type=SYSCALL msg=audit(1603177114.816:1686): arch=c000003e syscall=192 success=no exit=-61 a0=7ffead7ecd80 a1=564192a7ad60 a2=0 a3=0 items=0 ppid=36334 pid=36464 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="rsync" exe="/usr/bin/rsync" subj=system_u:system_r:rsync_t:s0 key=(null)�ARCH=x86_64 SYSCALL=lgetxattr AUID="unset" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root" type=PROCTITLE msg=audit(1603177114.816:1686): proctitle=7273796E63002D615230002D2D696E706C616365002D2D66696C65732D66726F6D3D2D002D2D7375706572002D2D7374617473002D2D6E756D657269632D696473002D2D6E6F2D696D706C6965642D64697273002D2D6C6F672D66696C653D2F746D702F726C6F67002D2D6578697374696E67002D2D786174747273002D2D61 type=AVC msg=audit(1603177114.820:1687): avc: denied { sys_admin } for pid=36464 comm="rsync" capability=21 scontext=system_u:system_r:rsync_t:s0 tcontext=system_u:system_r:rsync_t:s0 tclass=capability permissive=0 type=SYSCALL msg=audit(1603177114.820:1687): arch=c000003e syscall=192 success=no exit=-61 a0=7ffead7ecd80 a1=564192a7ad60 a2=0 a3=0 items=0 ppid=36334 pid=36464 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="rsync" exe="/usr/bin/rsync" subj=system_u:system_r:rsync_t:s0 key=(null)�ARCH=x86_64 SYSCALL=lgetxattr AUID="unset" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root" type=PROCTITLE msg=audit(1603177114.820:1687): proctitle=7273796E63002D615230002D2D696E706C616365002D2D66696C65732D66726F6D3D2D002D2D7375706572002D2D7374617473002D2D6E756D657269632D696473002D2D6E6F2D696D706C6965642D64697273002D2D6C6F672D66696C653D2F746D702F726C6F67002D2D6578697374696E67002D2D786174747273002D2D61 type=AVC msg=audit(1603177114.821:1688): avc: denied { sys_admin } for pid=36464 comm="rsync" capability=21 scontext=system_u:system_r:rsync_t:s0 tcontext=system_u:system_r:rsync_t:s0 tclass=capability permissive=0 type=SYSCALL msg=audit(1603177114.821:1688): arch=c000003e syscall=192 success=no exit=-61 a0=7ffead7ecd80 a1=564192a7ad60 a2=0 a3=0 items=0 ppid=36334 pid=36464 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="rsync" exe="/usr/bin/rsync" subj=system_u:system_r:rsync_t:s0 key=(null)�ARCH=x86_64 SYSCALL=lgetxattr AUID="unset" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root" type=PROCTITLE msg=audit(1603177114.821:1688): proctitle=7273796E63002D615230002D2D696E706C616365002D2D66696C65732D66726F6D3D2D002D2D7375706572002D2D7374617473002D2D6E756D657269632D696473002D2D6E6F2D696D706C6965642D64697273002D2D6C6F672D66696C653D2F746D702F726C6F67002D2D6578697374696E67002D2D786174747273002D2D61 type=SERVICE_STOP msg=audit(1603177534.663:1689): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd-kcm comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'�UID="root" AUID="unset" 


Expected results: rsync should be able to sync data.


Additional info: On using audit2allow the output is as follows,

module rsyncCustomRule 1.0;

require {
        type rsync_t;
        class capability sys_admin;
}

#============= rsync_t ==============
allow rsync_t self:capability sys_admin;

Comment 4 Zdenek Pytela 2020-10-20 15:42:34 UTC
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?

Comment 5 Srijan Sivakumar 2020-10-20 15:54:19 UTC
(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.

Comment 6 Zdenek Pytela 2020-10-20 16:32:16 UTC
(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.

Comment 9 Zdenek Pytela 2020-10-21 10:32:36 UTC
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.

Comment 10 SATHEESARAN 2020-10-22 13:44:09 UTC
(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 ?

Comment 12 Zdenek Pytela 2020-11-04 18:56:15 UTC
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?

Comment 13 Srijan Sivakumar 2020-11-05 03:43:24 UTC
 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

Comment 14 Srijan Sivakumar 2020-11-26 04:05:51 UTC
 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


Note You need to log in before you can comment on or make changes to this bug.