Bug 1955036 - flatpak install throws revokefs-fuse: remote peer disconnected
Summary: flatpak install throws revokefs-fuse: remote peer disconnected
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: flatpak
Version: 34
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: David King
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-04-29 10:27 UTC by Ryan
Modified: 2022-06-07 20:03 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-06-07 20:03:09 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Ryan 2021-04-29 10:27:25 UTC
Description of problem:
installing flatpaks as local user results in the following error:

`Warning: Failed to get revokefs-fuse socket from system-helper: Remote peer disconnected`

Version-Release number of selected component (if applicable):
1.10.2-3.fc34.x86_64

How reproducible:
everytime I install a flatpak

Steps to Reproduce:
1. add flathub repo
2. `flatpak install <package>`
3. receive error

Actual results:
error as above

Expected results:
no error

Additional info:
clean install of F34 KDE edition. 
flatpak-system-helper.service is running.
no related errors in user or system journal

Comment 1 Ryan 2021-05-15 00:38:43 UTC
after some research on this matter I have found that it could be selinux related, however I am not currently getting any AVC denials. when I get time I will test in permissive mode

Comment 2 Ryan 2021-05-19 13:19:46 UTC
Tested in permissive mode. Flatpak update did not throw this error. I'm still not seeing any avc denials though. Currently trying to find a way to extract why it's being prevented by SELinux.

Comment 3 Ryan 2021-05-19 14:17:13 UTC
ok so I enabled the don't audit rules and ran an install. I got the following avc denials:

$ sealert -l "*"
SELinux is preventing SetroubleshootP from using the siginh access on a process.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that SetroubleshootP should be allowed siginh access on processes labeled unconfined_service_t by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'SetroubleshootP' --raw | audit2allow -M my-SetroubleshootP
# semodule -X 300 -i my-SetroubleshootP.pp


Additional Information:
Source Context                system_u:system_r:init_t:s0
Target Context                system_u:system_r:unconfined_service_t:s0
Target Objects                Unknown [ process ]
Source                        SetroubleshootP
Source Path                   SetroubleshootP
Port                          <Unknown>
Host                          myhost
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-34.7-1.fc34.noarch
Local Policy RPM              selinux-policy-targeted-34.7-1.fc34.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     myhost
Platform                      Linux myhost 5.11.21-300.fc34.x86_64 #1
                              SMP Fri May 14 17:43:38 UTC 2021 x86_64 x86_64
Alert Count                   2
First Seen                    2021-05-19 21:59:19 AWST
Last Seen                     2021-05-19 21:59:37 AWST
Local ID                      59915757-8a33-4f2c-8d09-f92a5a72e49f

Raw Audit Messages
type=AVC msg=audit(1621432777.404:1431): avc:  denied  { siginh } for  pid=20469 comm="flatpak-system-" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process permissive=0


Hash: SetroubleshootP,init_t,unconfined_service_t,process,siginh

SELinux is preventing pkla-check-auth from using the rlimitinh access on a process.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that pkla-check-auth should be allowed rlimitinh access on processes labeled policykit_auth_t by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'pkla-check-auth' --raw | audit2allow -M my-pklacheckauth
# semodule -X 300 -i my-pklacheckauth.pp


Additional Information:
Source Context                system_u:system_r:policykit_t:s0
Target Context                system_u:system_r:policykit_auth_t:s0
Target Objects                Unknown [ process ]
Source                        pkla-check-auth
Source Path                   pkla-check-auth
Port                          <Unknown>
Host                          myhost
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-34.7-1.fc34.noarch
Local Policy RPM              selinux-policy-targeted-34.7-1.fc34.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     myhost
Platform                      Linux myhost 5.11.21-300.fc34.x86_64 #1
                              SMP Fri May 14 17:43:38 UTC 2021 x86_64 x86_64
Alert Count                   28
First Seen                    2021-05-19 21:59:13 AWST
Last Seen                     2021-05-19 21:59:45 AWST
Local ID                      3360fc13-ba2d-4a16-87fa-1c6c20cc011d

Raw Audit Messages
type=AVC msg=audit(1621432785.366:1470): avc:  denied  { rlimitinh } for  pid=20554 comm="pkla-check-auth" scontext=system_u:system_r:policykit_t:s0 tcontext=system_u:system_r:policykit_auth_t:s0 tclass=process permissive=0


Hash: pkla-check-auth,policykit_t,policykit_auth_t,process,rlimitinh

SELinux is preventing unix_chkpwd from 'read, write' accesses on the chr_file /dev/pts/1.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that unix_chkpwd should be allowed read write access on the 1 chr_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'unix_chkpwd' --raw | audit2allow -M my-unixchkpwd
# semodule -X 300 -i my-unixchkpwd.pp


Additional Information:
Source Context                unconfined_u:unconfined_r:chkpwd_t:s0-s0:c0.c1023
Target Context                unconfined_u:object_r:user_devpts_t:s0
Target Objects                /dev/pts/1 [ chr_file ]
Source                        unix_chkpwd
Source Path                   unix_chkpwd
Port                          <Unknown>
Host                          myhost
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-34.7-1.fc34.noarch
Local Policy RPM              selinux-policy-targeted-34.7-1.fc34.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     myhost
Platform                      Linux myhost 5.11.21-300.fc34.x86_64 #1
                              SMP Fri May 14 17:43:38 UTC 2021 x86_64 x86_64
Alert Count                   1
First Seen                    2021-05-19 21:59:50 AWST
Last Seen                     2021-05-19 21:59:50 AWST
Local ID                      d0891a18-d79a-4f06-b797-93aa98813c3f

Raw Audit Messages
type=AVC msg=audit(1621432790.440:1472): avc:  denied  { read write } for  pid=20591 comm="unix_chkpwd" path="/dev/pts/1" dev="devpts" ino=4 scontext=unconfined_u:unconfined_r:chkpwd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file permissive=0


Hash: unix_chkpwd,chkpwd_t,user_devpts_t,chr_file,read,write

Comment 4 Ryan 2021-05-19 14:44:48 UTC
after reading through the audit logs, I believe something similar to the below modules will probably be what is required:

module my-FlatpakSystem 1.0;

require {
        type init_t;
        type unconfined_service_t;
        class process siginh;
}

#============= init_t ==============

#!!!! This avc has a dontaudit rule in the current policy
allow init_t unconfined_service_t:process siginh;

module my-DbusBroker 1.0;

require {
        type unconfined_service_t;
        type system_dbusd_t;
        class unix_stream_socket { read write };
}

#============= system_dbusd_t ==============

#!!!! This avc has a dontaudit rule in the current policy
allow system_dbusd_t unconfined_service_t:unix_stream_socket { read write };

Comment 5 Ben Cotton 2022-05-12 14:55:32 UTC
This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 6 Ben Cotton 2022-06-07 20:03:09 UTC
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07.

Fedora Linux 34 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release.

Thank you for reporting this bug and we are sorry it could not be fixed.


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