Bug 2070741 - flatpak_helper_t unable to open, read and lock files inside /var/lib/flatpak
Summary: flatpak_helper_t unable to open, read and lock files inside /var/lib/flatpak
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: flatpak
Version: 36
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Debarshi Ray
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:7890417aefe265361726257f062...
: 2053631 2070739 2070742 2070750 2072246 2072274 (view as bug list)
Depends On:
Blocks: 2075937 F36FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2022-03-31 19:52 UTC by Flo H.
Modified: 2022-05-11 21:06 UTC (History)
15 users (show)

Fixed In Version: flatpak-1.12.7-2.fc36
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-04-14 23:23:55 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github flatpak flatpak pull 4855 0 None open selinux: Permit read access to /var/lib/flatpak 2022-04-12 20:42:20 UTC

Description Flo H. 2022-03-31 19:52:19 UTC
Description of problem:
I guess flatpak update caused this problem
SELinux is preventing pool-/usr/libex from 'read' accesses on the lnk_file /var/lib/flatpak/runtime/org.gnome.Platform/x86_64/40/active.

*****  Plugin catchall_labels (83.8 confidence) suggests   *******************

If you want to allow libex to have read access on the active lnk_file
Then you need to change the label on /var/lib/flatpak/runtime/org.gnome.Platform/x86_64/40/active
Do
# semanage fcontext -a -t FILE_TYPE '/var/lib/flatpak/runtime/org.gnome.Platform/x86_64/40/active'
where FILE_TYPE is one of the following: admin_home_t, bin_t, boot_t, device_t, etc_runtime_t, etc_t, fonts_cache_t, fonts_t, ld_so_t, lib_t, locale_t, man_cache_t, man_t, proc_t, root_t, rpm_script_tmp_t, security_t, shell_exec_t, src_t, system_conf_t, system_db_t, system_dbusd_var_lib_t, textrel_shlib_t, tmp_t, usr_t, var_run_t, var_t.
Then execute:
restorecon -v '/var/lib/flatpak/runtime/org.gnome.Platform/x86_64/40/active'


*****  Plugin catchall (17.1 confidence) suggests   **************************

If you believe that libex should be allowed read access on the active lnk_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 'pool-/usr/libex' --raw | audit2allow -M my-poolusrlibex
# semodule -X 300 -i my-poolusrlibex.pp

Additional Information:
Source Context                system_u:system_r:flatpak_helper_t:s0
Target Context                system_u:object_r:var_lib_t:s0
Target Objects                /var/lib/flatpak/runtime/org.gnome.Platform/x86_64
                              /40/active [ lnk_file ]
Source                        pool-/usr/libex
Source Path                   pool-/usr/libex
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-36.5-1.fc36.noarch
Local Policy RPM              flatpak-selinux-1.12.7-1.fc36.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 5.17.0-300.fc36.x86_64 #1 SMP
                              PREEMPT Wed Mar 23 22:00:40 UTC 2022 x86_64 x86_64
Alert Count                   40
First Seen                    2022-03-31 21:43:32 CEST
Last Seen                     2022-03-31 21:47:28 CEST
Local ID                      0eb1b76a-9a0f-4e83-aabc-c5f607379938

Raw Audit Messages
type=AVC msg=audit(1648756048.256:1802): avc:  denied  { read } for  pid=46399 comm="pool-/usr/libex" name="active" dev="dm-1" ino=1584753 scontext=system_u:system_r:flatpak_helper_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=lnk_file permissive=0


Hash: pool-/usr/libex,flatpak_helper_t,var_lib_t,lnk_file,read

Version-Release number of selected component:
selinux-policy-targeted-36.5-1.fc36.noarch

Additional info:
component:      flatpak
reporter:       libreport-2.17.1
hashmarkername: setroubleshoot
kernel:         5.17.0-300.fc36.x86_64
type:           libreport

Comment 1 Debarshi Ray 2022-04-01 20:46:12 UTC
There's also bug 2053631, which is about:
SELinux is preventing pool-/usr/libex from 'read' accesses on the directory /var/lib/flatpak/repo.

Comment 2 Debarshi Ray 2022-04-01 20:46:29 UTC
*** Bug 2053631 has been marked as a duplicate of this bug. ***

Comment 3 Debarshi Ray 2022-04-01 20:47:56 UTC
*** Bug 2070742 has been marked as a duplicate of this bug. ***

Comment 4 Debarshi Ray 2022-04-01 20:48:07 UTC
*** Bug 2070739 has been marked as a duplicate of this bug. ***

Comment 5 Debarshi Ray 2022-04-01 21:20:34 UTC
*** Bug 2070750 has been marked as a duplicate of this bug. ***

Comment 6 Debarshi Ray 2022-04-12 19:26:16 UTC
I think these are all SELinux denials caused by the flatpak_helper_t SELinux domain not being able to read files inside /var/lib/flatpak.  This should clearly be allowed.

Zdeněk, any suggestions?

Comment 7 Zdenek Pytela 2022-04-12 19:50:18 UTC
As long as it is only reading,

files_read_var_lib_files(flatpak_helper_t)

should do it, possibly also

files_list_var_lib(flatpak_helper_t)
files_read_var_lib_files(flatpak_helper_t)

Comment 8 Debarshi Ray 2022-04-12 20:42:21 UTC
Does this look good to you:
https://github.com/flatpak/flatpak/pull/4855 ?

Comment 9 Fedora Update System 2022-04-12 21:33:13 UTC
FEDORA-2022-bc3af3f0d1 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-bc3af3f0d1

Comment 10 Zdenek Pytela 2022-04-13 07:58:09 UTC
It looks good.

Comment 11 František Zatloukal 2022-04-13 14:42:02 UTC
Discussed in ticket: https://pagure.io/fedora-qa/blocker-review/issue/747

The decision to classify this bug as an AcceptedFreezeException was made:

"There is a high probability that this issue can be hit by users right after Fedora installation before updating their systems. It was decided to take this in during the Freeze."

Comment 12 Fedora Update System 2022-04-13 19:48:52 UTC
FEDORA-2022-bc3af3f0d1 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-bc3af3f0d1`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-bc3af3f0d1

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 13 Fedora Update System 2022-04-14 23:23:55 UTC
FEDORA-2022-bc3af3f0d1 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 14 Debarshi Ray 2022-05-11 11:45:22 UTC
*** Bug 2072274 has been marked as a duplicate of this bug. ***

Comment 15 Debarshi Ray 2022-05-11 21:05:50 UTC
*** Bug 2072246 has been marked as a duplicate of this bug. ***


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