Created attachment 1821114 [details] Journalctl from the affected machines Description of problem: On Fedora 35 Beta, the g-i-s provides a screen where Fedora Third Party repositories can be switched on, however when this screen is used to switch on the Third Party repos, they remain switched off in Software which also suggests to switch them on. Version-Release number of selected component (if applicable): gnome-session-40.1.1-2.fc35.x86_64 gnome-initial-setup-41~beta-3.fc35.x86_64 gnome-software-41~beta-3.fc35.x86_64 How reproducible: Always Steps to Reproduce: 1. Fresh install Fedora Workstation 35 and wait until g-i-s starts (it can take upto 2 minutes). 2. Create the username and password. 3. Switch on the Fedora Third Party repos and finish the wizard. 4. Open Software and check if Third Party repos are switched on -> they are not. Actual results: Gnome Initial Setup cannot switch the Third party repos on. Expected results: If such option is there, Gnome initial setup should be able to use it.
Adam, did this work for you when you tested it recently?
I've seen this issue testing the nightly from 6 September.
I've been trying to get a terminal in the gnome-initial-setup session so that I can investigate this, but I've only failed so far. I first tried dropping an autostart file to launch gnome-terminal into /mnt/somethingorother/etc/xdg/autostart after finishing anaconda, so that it's present in the installed system when booted for the first time, but that actually causes the entire initial setup session to crash. Bug #1997310 isn't helping either. But worst of all is bug #2003253, I cannot type because the keyboard layout is messed up. Of course, attempting to debugging that is going to be equivalently tough....
I have a suspicion though: it could be related to bug #1997310. Everything D-Bus related seems to be broken right now, which could have consequences for pretty much anything. My suggestion is to wait until that is fixed before worrying more about this.
As I mentioned on the other bug, after installing but before rebooting you can chroot into the installed system and set a password for root so you can log in while g-i-s is running.
When I forced my way past gnome-initial-setup, enabling third-party repositories using the opt-in infobar in gnome-software worked as expected, so this seems to be something specific to the gnome-initial-setup environment.
This might be the same as bug 2003778 - selinux prevents gnome-initial-setup actions/configs from being executed/applied. Lukas, can you test with enforcing=0?
Turns out the problem here was: I made gnome-initial-setup run '/usr/bin/fedora-third-party enabled' but it should be '/usr/bin/fedora-third-party enable' 🤦 So I will release an update that will definitely fix this particular error. That's no guarantee the feature will actually work -- it's impossible to be sure before this update reaches a compose, so testing is much appreciated once it does -- but I'm feeling confident.
Proposed as a Freeze Exception for 35-beta by Fedora user catanzaro using the blocker tracking app because: In F35, gnome-initial-setup has a new page that allows users to choose to enable selected third-party repositories. Problem is the switch is broken and so effectively does nothing. The fix is very simple, and would be nice to get it into beta if time permits.
FEDORA-2021-3e83b4cfc8 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3e83b4cfc8
+3 in https://pagure.io/fedora-qa/blocker-review/issue/455 , marking accepted.
This issue still persists on 20210915 Workstation compose which uses gnome-initial-setup-41~beta-3.f35.
yes, we have not pushed the fix stable yet. you could grab the ISO openQA built for the update and test that, if it hasn't been wiped yet.
(In reply to Fedora Update System from comment #10) > FEDORA-2021-3e83b4cfc8 has been submitted as an update to Fedora 35. > https://bodhi.fedoraproject.org/updates/FEDORA-2021-3e83b4cfc8 Newer update is here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-fc156dedfd It has 0 karma currently, but that is expected because it's pretty difficult to test before it reaches a compose.
FEDORA-2021-fc156dedfd has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-fc156dedfd` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-fc156dedfd See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
https://openqa.stg.fedoraproject.org/tests/1328411/asset/iso/01328411-Fedora-Workstation-Live-x86_64-FEDORA-2021-fc156dedfd.iso is an ISO which should include this build, for testing.
I tested, it looks like it worked. After toggling the switch in g-i-s, Software doesn't prompt me to turn on third party repos, and shows Chrome in the search results for 'chrom'.
Thanks for testing!
FEDORA-2021-fc156dedfd has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
Still broken when I tested it in today's nightly image. I see in my journal: Sep 18 18:36:07 localhost-live pkexec[1972]: pam_unix(polkit-1:session): session opened for user root(uid=0) by (uid=983) Sep 18 18:36:07 localhost-live audit[1972]: USER_START pid=1972 uid=983 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" > Sep 18 18:36:07 localhost-live pkexec[1972]: gnome-initial-setup: Executing command [USER=root] [TTY=unknown] [CWD=/run/gnome-initial-setup/] [COMMAND=/usr/bin/fedora-third-party enable] Sep 18 18:36:07 localhost-live polkitd[1023]: Registered Authentication Agent for unix-process:1975:3329 (system bus name :1.106 [flatpak remotes --system --columns=name,filter], object path /org/freedesktop/PolicyKit1/AuthenticationAgen> Sep 18 18:36:07 localhost-live polkitd[1023]: Unregistered Authentication Agent for unix-process:1975:3329 (system bus name :1.106, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) Sep 18 18:36:07 localhost-live polkitd[1023]: Registered Authentication Agent for unix-process:1983:3336 (system bus name :1.107 [flatpak remote-add --from flathub /usr/lib/fedora-third-party/conf.d/fedora-flathub.flatpakrepo], object pa> Sep 18 18:36:07 localhost-live audit[1983]: AVC avc: denied { unlink } for pid=1983 comm="flatpak" name="config" dev="vda2" ino=155646 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file> Sep 18 18:36:07 localhost-live polkitd[1023]: Unregistered Authentication Agent for unix-process:1983:3336 (system bus name :1.107, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1983]: error: renameat(./tmp.W6kuTS, config): Permission denied Sep 18 18:36:07 localhost-live python3[1972]: detected unhandled Python exception in '/usr/bin/fedora-third-party' Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: Traceback (most recent call last): Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: File "/usr/bin/fedora-third-party", line 33, in <module> Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: sys.exit(load_entry_point('fedora-third-party==0.6', 'console_scripts', 'fedora-third-party')()) Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: File "/usr/lib/python3.10/site-packages/click/core.py", line 1137, in __call__ Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: return self.main(*args, **kwargs) Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: File "/usr/lib/python3.10/site-packages/click/core.py", line 1062, in main Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: rv = self.invoke(ctx) Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: File "/usr/lib/python3.10/site-packages/click/core.py", line 1668, in invoke Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: return _process_result(sub_ctx.command.invoke(sub_ctx)) Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: File "/usr/lib/python3.10/site-packages/click/core.py", line 1404, in invoke Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: return ctx.invoke(self.callback, **ctx.params) Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: File "/usr/lib/python3.10/site-packages/click/core.py", line 763, in invoke Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: return __callback(*args, **kwargs) Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: File "/usr/lib/python3.10/site-packages/click/decorators.py", line 84, in new_func Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: return ctx.invoke(f, obj, *args, **kwargs) Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: File "/usr/lib/python3.10/site-packages/click/core.py", line 763, in invoke Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: return __callback(*args, **kwargs) Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: File "/usr/lib/python3.10/site-packages/fedora_third_party/cli.py", line 42, in enable Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: repository.enable() Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: File "/usr/lib/python3.10/site-packages/fedora_third_party/repository.py", line 94, in enable Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: self.run_flatpak(['remote-add', '--from', self.name, self.flatpakrepo]) Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: File "/usr/lib/python3.10/site-packages/fedora_third_party/repository.py", line 89, in run_flatpak Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: subprocess.check_call(command) Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: File "/usr/lib64/python3.10/subprocess.py", line 369, in check_call Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: raise CalledProcessError(retcode, cmd) Sep 18 18:36:07 localhost-live gnome-initial-setup.desktop[1972]: subprocess.CalledProcessError: Command '['flatpak', 'remote-add', '--from', 'flathub', '/usr/lib/fedora-third-party/conf.d/fedora-flathub.flatpakrepo']' returned non-zero > Sep 18 18:36:07 localhost-live gnome-initial-s[1734]: /usr/bin/fedora-third-party failed: /usr/bin/fedora-third-party failed: Child process exited with code Reopening and reassigning to fedora-third-party, since this doesn't appear to be gnome-initial-setup's fault anymore.
ah, I may have tested in permissive mode to avoid the earlier selinux issues...does it work in permissive mode for you?
Actually it does: Sep 19 11:14:32 localhost-live pkexec[1917]: pam_unix(polkit-1:session): session opened for user root(uid=0) by (uid=983) Sep 19 11:14:32 localhost-live audit[1917]: USER_START pid=1917 uid=983 auid=4294967295 ses=4294967295 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_s> Sep 19 11:14:32 localhost-live pkexec[1917]: gnome-initial-setup: Executing command [USER=root] [TTY=unknown] [CWD=/run/gnome-initial-setup/] [COMMAND=/usr/bin/fedor> Sep 19 11:14:32 localhost-live polkitd[974]: Registered Authentication Agent for unix-process:1920:1978 (system bus name :1.115 [flatpak remotes --system --columns=n> Sep 19 11:14:32 localhost-live polkitd[974]: Unregistered Authentication Agent for unix-process:1920:1978 (system bus name :1.115, object path /org/freedesktop/Polic> Sep 19 11:14:32 localhost-live polkitd[974]: Registered Authentication Agent for unix-process:1928:1984 (system bus name :1.116 [flatpak remote-add --from flathub /u> Sep 19 11:14:32 localhost-live flatpak[1928]: system: Added remote flathub to https://dl.flathub.org/repo/ Sep 19 11:14:33 localhost-live flatpak[1928]: system: Modified remote flathub to https://dl.flathub.org/repo/ So I suppose it's probably broken due to: Sep 18 18:36:07 localhost-live audit[1983]: AVC avc: denied { unlink } for pid=1983 comm="flatpak" name="config" dev="vda2" ino=155646 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file>
One thing I'm a bit mystified by is that the AVC implies that the denial is for the *flatpak* binary. But the way I'd expect this to happen is that actual modification of /var/lib/flatpak would be done by flatpak-system-helper, which is activated by systemd and would not have the xdm_t scontext. But I don't see how we could be going down the "no system helper" code path in flatpak-dir.c - that would only be used if: * the remote is a user remote, not in /var/lib * geteuid() == 0 * running inside the system helper process already * installing an OCI *flatpak* (not adding an OCI remote) I'm probably misreading either the AVC or the flatpak code :-)
OK, played around with this a bit, and the obvious thing I was missing is that the gnome-initial-setup user is not running flatpak remote-add --from flathub /usr/lib/fedora-third-party/conf.d/fedora-flathub.flatpakrepo' Rather, the gnome-initial-setup user runs: pkexec fedora-third-party enable And that, *as root*, runs flatpak remote-add --from flathub /usr/lib/fedora-third-party/conf.d/fedora-flathub.flatpakrepo'. It appears that the pkexec leaves the selinux context unchanged, hence the denials. Note that the denial that is causing the traceback is the "tip of the iceberg". The full set I get with setenforce 0 is: === type=AVC msg=audit(1632242294.255:24226): avc: denied { unlink } for pid=2507 comm="flatpak" name="config" dev="vda2" ino=163736 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=1 type=AVC msg=audit(1632242294.296:24227): avc: denied { write } for pid=2507 comm="flatpak" name="flathub.filter" dev="vda2" ino=163731 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=1 type=AVC msg=audit(1632242294.385:24228): avc: denied { write } for pid=2507 comm="flatpak" name=".changed" dev="vda2" ino=155634 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=1 type=AVC msg=audit(1632242294.587:24229): avc: denied { map } for pid=2507 comm="flatpak" path="/var/lib/flatpak/repo/tmp/cache/summaries/flathub-x86_64-4fa6217afcba903c3b36853f89ebae7bdf6b2d6a8b4877a0e4ecc6599b49836f.sub" dev="vda2" ino=163694 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=1 type=AVC msg=audit(1632242294.725:24230): avc: denied { add_name } for pid=2496 comm="fedora-third-pa" name="_copr_phracek-PyCharm.repo.g6lhgjqs" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_conf_t:s0 tclass=dir permissive=1 type=AVC msg=audit(1632242294.725:24231): avc: denied { create } for pid=2496 comm="fedora-third-pa" name="_copr_phracek-PyCharm.repo.g6lhgjqs" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_conf_t:s0 tclass=file permissive=1 type=AVC msg=audit(1632242294.725:24232): avc: denied { write } for pid=2496 comm="fedora-third-pa" path="/etc/yum.repos.d/_copr_phracek-PyCharm.repo.g6lhgjqs" dev="vda2" ino=166216 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_conf_t:s0 tclass=file permissive=1 type=AVC msg=audit(1632242294.725:24233): avc: denied { setattr } for pid=2496 comm="fedora-third-pa" name="_copr_phracek-PyCharm.repo.g6lhgjqs" dev="vda2" ino=166216 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_conf_t:s0 tclass=file permissive=1 type=AVC msg=audit(1632242294.726:24234): avc: denied { relabelfrom } for pid=2560 comm="chcon" name="_copr_phracek-PyCharm.repo.g6lhgjqs" dev="vda2" ino=166216 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_conf_t:s0 tclass=file permissive=1 type=AVC msg=audit(1632242294.726:24235): avc: denied { relabelto } for pid=2560 comm="chcon" name="_copr_phracek-PyCharm.repo.g6lhgjqs" dev="vda2" ino=166216 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_conf_t:s0 tclass=file permissive=1 type=AVC msg=audit(1632242294.726:24236): avc: denied { remove_name } for pid=2496 comm="fedora-third-pa" name="_copr_phracek-PyCharm.repo.g6lhgjqs" dev="vda2" ino=166216 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_conf_t:s0 tclass=dir permissive=1 type=AVC msg=audit(1632242294.726:24237): avc: denied { rename } for pid=2496 comm="fedora-third-pa" name="_copr_phracek-PyCharm.repo.g6lhgjqs" dev="vda2" ino=166216 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_conf_t:s0 tclass=file permissive=1 type=AVC msg=audit(1632242294.726:24238): avc: denied { unlink } for pid=2496 comm="fedora-third-pa" name="_copr_phracek-PyCharm.repo" dev="vda2" ino=163739 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_conf_t:s0 tclass=file permissive=1 === Which when run through audit2allow gives: === allow xdm_t system_conf_t:dir { add_name remove_name }; allow xdm_t system_conf_t:file { create relabelfrom relabelto rename setattr unlink write }; allow xdm_t var_lib_t:file { unlink write }; #!!!! This avc can be allowed using the boolean 'domain_can_mmap_files' allow xdm_t var_lib_t:file map; === There are *no* denials from 'fedora-third-party disable' - this is because gnome-initial-setup runs, /var/lib/fedora-third-party/state typically does not exist, and it is then created as xdm_var_lib_t, and permissions exist to manage that. If it was created previously, then 'fedora-third-party disable' wouldn't work. Translating all of the above into selinux-policy changes is something I don't really have the background to do. I'm *not* convinced that we should just give the xdm_t type the ability to edit arbitrary files in /etc, but I don't know how feasible it would be to make 'pkexec fedora-third-party' transition to a different context with more permissions. (This context would need additional permissions compared to the above - the above are just the ones that the current context doesn't have.)
Proposed as a Blocker for 35-final by Fedora user catanzaro using the blocker tracking app because: "If an initial setup utility is run or intended to be run after the first boot of the installed system, then it must start successfully and each page or panel of the initial setup utility should withstand a basic functionality test."
+5 in https://pagure.io/fedora-qa/blocker-review/issue/455 , marking accepted.
Hi Zdenek! Do you have all the info needed for this one now? Do you think it can/should be fixed in SELinux policy? It's a Final blocker, and Final is coming up relatively soon. Thanks!
*** Bug 2005470 has been marked as a duplicate of this bug. ***
I am working on resolving this problem.
This still happening Fedora-Workstation-Live-x86_64-35-20211004.n.0.iso gnome-initial-setup-41.0-1.fc35.x86_64 gnome-session-40.1.1-2.fc35.x86_64 gnome-session-wayland-session-40.1.1-2.fc35.x86_64 gnome-session-xsession-40.1.1-2.fc35.x86_64 gnome-software-41.0-1.fc35.x8
Yes, as per the comment above yours, Zdenek is still working on it, i.e. it isn't fixed yet.
There are 2 problems, not directly related: - Fedora Third Party Repositories - Flatpak remote-add I have a new policy for fedora-third-party, it seems to work and Enable New Repositories button is turned on after setup finishes. gnome-initial-setup should probably be SELinux confined, but it is not a task for this moment. I will create a PR and add more details soon.
There is a draft PR for new SELinux policy for fedora-third-party: https://github.com/fedora-selinux/selinux-policy/pull/905 How to download rpms: Show all checks -> build-rpm -> Details -> Artifacts -> rpms It does not completely resolve issues with flatpak, it requires further attention, but the issue as reported: "The switch for Fedora Third Party repositories does not switch them on" seems to be gone.
Unfortunately, new policy modules require a new package, so the rpms from the PR won't work. I will do it tomorrow.
Thanks for working on this! The pull request looks reasonable as far as my knowledge of selinux goes. It's probably obvious, but we do need to handle "flatpak remote-add" as well to resolve this issue - if fedora-third-party can edit the DNF repositories, but fails to create Flatpak repositories, then things are going to be left in an inconsistent state.
A scratchbuild available here: https://koji.fedoraproject.org/koji/taskinfo?taskID=76873076
FEDORA-2021-a74259b82b has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-a74259b82b
I can confirm that with the latest update (comment #37), the issue is fixed and now the G-I-S can be used to allow the Third Party Repos.
FEDORA-2021-a74259b82b has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-a74259b82b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a74259b82b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Owen Taylor from comment #35) > Thanks for working on this! The pull request looks reasonable as far as my > knowledge of selinux goes. It's probably obvious, but we do need to handle > "flatpak remote-add" as well to resolve this issue - if fedora-third-party > can edit the DNF repositories, but fails to create Flatpak repositories, > then things are going to be left in an inconsistent state. So did the problem with 'flatpak remote-add' get fixed?
FEDORA-2021-a74259b82b has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
I downloaded Fedora-Workstation-Live-x86_64-35-20211010.n.0.iso todaym which includes gnome-initial-setup-41.0-1.fc35.x86_64 and selinux-policy-35.1-1.fc35.noarch. After enabling third party repos in the initial setup, neither the RPM repos nor the flathub repo is enabled in the final system. In journal I see this: Oct 11 12:15:30 localhost-live pkexec[1534]: gnome-initial-setup: Executing command [USER=root] [TTY=unknown] [CWD=/run/gnome-initial-setup/] [COMMAND=/usr/bin/fedora-third-party enable] Oct 11 12:15:30 localhost-live audit[1537]: AVC avc: denied { sys_nice } for pid=1537 comm="flatpak" capability=23 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=capability permissive=0 Oct 11 12:15:30 localhost-live audit[1537]: AVC avc: denied { setsched } for pid=1537 comm="flatpak" scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=process permissive=0 Oct 11 12:15:30 localhost-live audit[1537]: AVC avc: denied { read } for pid=1537 comm="flatpak" name="repo" dev="vda2" ino=155454 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=dir permissive=0 Oct 11 12:15:30 localhost-live audit[1534]: AVC avc: denied { create } for pid=1534 comm="fedora-third-pa" scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=unix_dgram_socket permissive=0 Oct 11 12:15:30 localhost-live gnome-initial-s[1385]: /usr/bin/fedora-third-party failed: /usr/bin/fedora-third-party failed: Child process exited with code 1 Lukas, you claimed it worked for you in comment 38, can you re-test with the latest ISO to confirm my findings?
I've downloaded Fedora-Workstation-Live-x86_64-35-20211011.n.0.iso and the Enable New Repositories button is turned on after g-i-s completes, although with a failure in the journal. This PR adds the create unix_dgram permission: https://github.com/fedora-selinux/selinux-policy/pull/908 Downloading rpms with the change: Show all checks -> build-rpm -> Details -> Artifacts -> rpms The other denials are popped by flatpak calling sched_setattr(2). - type=PROCTITLE msg=audit(11.10.2021 17:14:10.634:250) : proctitle=flatpak remotes --system --columns=name,filter type=SYSCALL msg=audit(11.10.2021 17:14:10.634:250) : arch=x86_64 syscall=sched_setattr success=no exit=EACCES(Permission denied) a0=0x5e4 a1=0x55937e98e800 a2=0x0 a3=0x0 items=0 ppid=1505 pid=1508 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=tty1 ses=unset comm=flatpak exe=/usr/bin/flatpak subj=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(11.10.2021 17:14:10.634:250) : avc: denied { setsched } for pid=1508 comm=flatpak scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=process permissive=0 type=AVC msg=audit(11.10.2021 17:14:10.634:250) : avc: denied { sys_nice } for pid=1508 comm=flatpak capability=sys_nice scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=capability permissive=0 ----
(In reply to Zdenek Pytela from comment #43) > The other denials are popped by flatpak calling sched_setattr(2). Pretty sure that is bug #1795524.
Zdenek, we need to check not just whether the button appears enabled, but whether it *worked* - whether the third party repositories actually are enabled, and you can find software from them.
I tested for myself and confirm Kamil's experience. The slider appears to work in g-i-s, but when I log in and run Software, I cannot find Chrome or the NVIDIA proprietary driver in the search results. When I look in the settings under "Fedora Third Party Repositories", the "Enable New Repositories" slider is enabled, but the Google Chrome and RPM Fusion NVIDIA and Steam repos are disabled. I see this in the logs: Oct 11 14:53:01 fedora pkexec[1521]: gnome-initial-setup: Executing command [USER=root] [TTY=unknown] [CWD=/run/gnome-initial-setup/] [COMMAND=/usr/bin/fedora-third-party enable] Oct 11 14:53:01 fedora audit[1524]: AVC avc: denied { sys_nice } for pid=1524 comm="flatpak" capability=23 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=capability permissive=0 Oct 11 14:53:01 fedora audit[1524]: AVC avc: denied { setsched } for pid=1524 comm="flatpak" scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=process permissive=0 Oct 11 14:53:01 fedora audit[1524]: AVC avc: denied { read } for pid=1524 comm="flatpak" name="repo" dev="vda2" ino=155460 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=dir permissive=0 Oct 11 14:53:01 fedora audit[1521]: AVC avc: denied { create } for pid=1521 comm="fedora-third-pa" scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=unix_dgram_socket permissive=0 Oct 11 14:53:01 fedora gnome-initial-s[1381]: /usr/bin/fedora-third-party failed: /usr/bin/fedora-third-party failed: Child process exited with code 1
I am having the same experience as Adam in comment #46. The Third Party repos are enabled per se, but any repository in that list is still disabled, so the system does not receive any RPMs from them.
This seems too fragile. Owen, would you like me to check the script's exit code and display some sort of error when it fails? We cannot do any particularly great error message with just an error code, but at least I could show "something went wrong" and flip the switch back to the failed state.
> Owen, would you like me to check the script's exit code and display some sort of error when it fails? We cannot do any particularly great error message with just an error code, but at least I could show "something went wrong" and flip the switch back to the failed state. I don't think that's useful - what is user supposed to do with this information? It's not like trying again is going to help. And after the failure, the repositories have been left semi-enabled and there's no good way to recover. I *could* try to make the script transaction-like: Enable the RPM repositories - if that fails, exit Enable the Flatpak repositories - if it fails, disable the RPM repositories, exit Write the global "enabled state" But even then, if it fails, g-i-s needs to just continue - there's no point in telling the user that it failed. They'll see the enablement banner in gnome-software. But really, this needs to be just fixed... why would we make users check a box when we know that it's going to do nothing and confuse them?
Well of course it would be a bug for fedora-third-party to fail. It just seems a little tricky to hide the errors and not realize anything went wrong until later when the system is installed. But you're right, the page actually does not run fedora-third-party when you check the box, it waits until you transition to the next page, so there wouldn't be time to show an error anyway. Just got to make sure the script never fails.
Can you help me how to debug further or how to find out what went wrong? I can't find any relevant information in the journal.
I installed your test packages from https://github.com/fedora-selinux/selinux-policy/pull/905, and tried, and the unix-dgram message from Adam's log goes away, but I still get the subsequent message where flatpak can't read var_lib_t - I get the following log: === Oct 12 13:53:48 ibm-p8-kvm-03-guest-02.virt.pnr.lab.eng.rdu2.redhat.com pkexec[1645]: gnome-initial-setup: Executing command [USER=root] [TTY=unknown] [CWD=/run/gnome-initial-setup/] [COMMAND=/usr/bin/fedora-third-party enable] Oct 12 13:53:48 ibm-p8-kvm-03-guest-02.virt.pnr.lab.eng.rdu2.redhat.com audit[1648]: AVC avc: denied { sys_nice } for pid=1648 comm="flatpak" capability=23 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=capability permissive=0 Oct 12 13:53:48 ibm-p8-kvm-03-guest-02.virt.pnr.lab.eng.rdu2.redhat.com audit[1648]: AVC avc: denied { setsched } for pid=1648 comm="flatpak" scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=process permissive=0 Oct 12 13:53:48 ibm-p8-kvm-03-guest-02.virt.pnr.lab.eng.rdu2.redhat.com audit[1648]: AVC avc: denied { read } for pid=1648 comm="flatpak" name="repo" dev="vda2" ino=160266 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=dir permissive=0 Oct 12 13:53:48 ibm-p8-kvm-03-guest-02.virt.pnr.lab.eng.rdu2.redhat.com gnome-initial-s[1472]: /usr/bin/fedora-third-party failed: /usr/bin/fedora-third-party failed: Child process exited with code 1 === Basically, ths needs to be cycled until flatpak stops getting permission errors - the log run in permissive mode in comment 24 might help. Let me see if I can figure out quick-reset instructions for an installed system.
Seems to work to: # systemctl rescue. # fedora-third-party disable # rm /var/lib/fedora-third-party/state # userdel -r <initial username>
So, *in addition to* the rules in https://github.com/fedora-selinux/selinux-policy/pull/908 - I needed the following rules to successfully get fedora-third-party to work under gnome-initial-setup: === # These are permissions needed for the flatpak binary to add a new remote allow fedoratp_t tmp_t:dir write; allow fedoratp_t var_lib_t:dir { add_name read remove_name write }; allow fedoratp_t var_lib_t:file { getattr link open read rename setattr unlink write }; # These are needed because fedora-third-party edits DNF config files by writing # to tempname and then does (effectively): # <write foo.repo.asdf1234> # chcon --reference=foo.repo foo.repo.asdf1234 # mv foo.repo.asdf1234 foo.repo allow fedoratp_t system_conf_t:file { relabelfrom relabelto }; === If the relabel permissions seem problematical, maybe the chcon can be avoided by making tempname look like foo-asdf3214.repo rather than foo.repo.12341 ? I haven't examined what the selinux rules are for labelling files in /etc/yum.repos.d/. If they aren't problematical, then I'd rather avoid having to do an update for fedora-third-party as well.
(In reply to Owen Taylor from comment #54) > So, *in addition to* the rules in > https://github.com/fedora-selinux/selinux-policy/pull/908 - I needed the > following rules to successfully get fedora-third-party to work under > gnome-initial-setup: > > === > # These are permissions needed for the flatpak binary to add a new remote > allow fedoratp_t tmp_t:dir write; > allow fedoratp_t var_lib_t:dir { add_name read remove_name write }; > allow fedoratp_t var_lib_t:file { getattr link open read rename setattr > unlink write }; > > # These are needed because fedora-third-party edits DNF config files by > writing > # to tempname and then does (effectively): > # <write foo.repo.asdf1234> > # chcon --reference=foo.repo foo.repo.asdf1234 > # mv foo.repo.asdf1234 foo.repo > allow fedoratp_t system_conf_t:file { relabelfrom relabelto }; > === > > If the relabel permissions seem problematical, maybe the chcon can be > avoided by making tempname look like foo-asdf3214.repo rather than > foo.repo.12341 ? I haven't examined what the selinux rules are for labelling > files in /etc/yum.repos.d/. If they aren't problematical, then I'd rather > avoid having to do an update for fedora-third-party as well. I think running chcon is not necessary. If the temporary files are created new, they should inherit the context from the parent directory.
> I think running chcon is not necessary. If the temporary files are created new, they should inherit the context from the parent directory. So, did some testing with the chcon removed, and from the gnome-initial-setup context, things end up as expected for the new files: $ ls -lZ /etc/yum.repos.d/google-chrome.rep -rw-r--r--. 1 root root system_u:object_r:system_conf_t:s0 198 Oct 13 13:24 google-chrome.repo But with 'pkexec fedora-third-party enable' - which is what GNOME Software does, we end up with: $ ls -lZ /etc/yum.repos.d/google-chrome.rep -rw-r--r--. 1 root root unconfined_u:object_r:system_conf_t:s0 198 Oct 13 13:24 google-chrome.repo Which is (if I recall) what I was trying to fix. Is there any harm to the file being labeled with unconfined_u, other than aesthetics? Any obvious way to fix it? Can we transition to the fedoratp domain for the 'pkexec fedora-third-party enable' case? (and sudo fedora-third-party enable)?
(In reply to Owen Taylor from comment #56) > > I think running chcon is not necessary. If the temporary files are created new, they should inherit the context from the parent directory. > > So, did some testing with the chcon removed, and from the > gnome-initial-setup context, things end up as expected for the new files: > > $ ls -lZ /etc/yum.repos.d/google-chrome.rep > -rw-r--r--. 1 root root system_u:object_r:system_conf_t:s0 198 Oct 13 > 13:24 google-chrome.repo > > But with 'pkexec fedora-third-party enable' - which is what GNOME Software > does, we end up with: > > $ ls -lZ /etc/yum.repos.d/google-chrome.rep > -rw-r--r--. 1 root root unconfined_u:object_r:system_conf_t:s0 198 Oct 13 > 13:24 google-chrome.repo > > Which is (if I recall) what I was trying to fix. Is there any harm to the > file being labeled with unconfined_u, other than aesthetics? There is no harm, on my system there are a lot of them: # restorecon -RFvn /etc |wc -l 94 # restorecon -Rvn /etc |wc -l 0 all just because of the unconfined_u user. > > Any obvious way to fix it? Can we transition to the fedoratp domain for the > 'pkexec fedora-third-party enable' case? (and sudo fedora-third-party > enable)? The fedoratp_t domain is only for a service, commands should work as usual. I have some more permissions: https://github.com/fedora-selinux/selinux-policy/pull/914 but that seems to be all for fedoratp_t now, I'll continue with the effort to confine flatpak, bz#2013407.
FEDORA-2021-d3cb1609c8 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-d3cb1609c8
OK, filed an update for a new version of fedora-third-party with the chcon call removed: https://bodhi.fedoraproject.org/updates/FEDORA-2021-d3cb1609c8 But we really need to figure out the minimal fix for the "fedora-third-party calls flatpak-remote-add" thing. Is there some reason we can't just add the permissions above directly to the fedoratp module for now? Trying to comprehensively create a policy for Flatpak for all uses seems likely to cause major system regressions if rushed.
FEDORA-2021-d3cb1609c8 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-d3cb1609c8` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-d3cb1609c8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I've submitted a PR to make f-t-p working, a new build should be created soon.
I got openQA to build an ISO with the f-t-p update included, I'll test that shortly and see if the bug is indeed fixed.
Still fails with fedora-third-party-0.8-1.fc35, unfortunately: Oct 18 12:09:25 fedora pkexec[1516]: gnome-initial-setup: Executing command [USER=root] [TTY=unknown] [CWD=/run/gnome-initial-setup/] [COMMAND=/usr/bin/fedora-third-party enable] Oct 18 12:09:25 fedora audit[1519]: AVC avc: denied { sys_nice } for pid=1519 comm="flatpak" capability=23 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=capability permissive=0 Oct 18 12:09:25 fedora audit[1519]: AVC avc: denied { setsched } for pid=1519 comm="flatpak" scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=process permissive=0 Oct 18 12:09:25 fedora audit[1519]: AVC avc: denied { read } for pid=1519 comm="flatpak" name="repo" dev="vda2" ino=155464 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=dir permissive=0 Oct 18 12:09:25 fedora audit[1516]: AVC avc: denied { create } for pid=1516 comm="fedora-third-pa" scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=unix_dgram_socket permissive=0 Oct 18 12:09:25 fedora gnome-initial-s[1361]: /usr/bin/fedora-third-party failed: /usr/bin/fedora-third-party failed: Child process exited with code 1 [root@fedora test]# rpm -q fedora-third-party fedora-third-party-0.8-1.fc35.noarch Zdenek, can we get the new selinux-policy build today? Thanks!
The former pair should not be critical; the latter has already been addressed in selinux-policy-35.2-1.fc35 https://bodhi.fedoraproject.org/updates/FEDORA-2021-7dd082a675
Unfortunately, there's a long string of additional denials not fixed by 35.2-1 that I missed earlier due to a bug in my reset-to-clean-state procedure. (When the flatpak remote addition partially succeeded it didn't get removed on the reset, so the next round didn't try again.) It gets tricky because at some point the denials end up for gpg_t, not for fedorapt_t ... there's interaction with the GPG confinement. I'll try to turn the crank enough to get a (hopefully correct) set of permissions tonight and hopefully Zdenek will figure out how to go from there.
Thanks. I'm testing a live ISO with the latest selinux-policy build too, but it sounds like that won't be enough. Note go/no-go is Thursday and we actually sorted out the KDE blockers, so we're down to this and the clevis bug as the last unaddressed blockers now; we really need a fix for this by tomorrow at latest to make Thursday...
Yeah, live image with selinux-policy-35.2-1.fc35 also has the bug. I could combine latest fedora-third-party and selinux-policy but it sounds like that wouldn't be enough.
So, the minimal set of additional rules in order to make this work, is: === allow fedoratp_t tmp_t:dir { create rmdir }; allow fedoratp_t tmp_t:file { create open unlink write }; === With those rules, flatpak successfully creates the remote, fedora-third-party finishes its operation. A lot of log spam is left behind. (more than before - because after adding the remote, flatpak tries to do some optional steps.) === 19 00:59:28 fedora pkexec[1586]: gnome-initial-setup: Executing command [USER=root] [TTY=unknown] [CWD=/run/gnome-initial-setup/] [COMMAND=/usr/bin/fedora-third-party enable] Oct 19 00:59:28 fedora audit[1589]: AVC avc: denied { sys_nice } for pid=1589 comm="flatpak" capability=23 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=capability permissive=0 Oct 19 00:59:28 fedora audit[1589]: AVC avc: denied { setsched } for pid=1589 comm="flatpak" scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=process permissive=0 Oct 19 00:59:28 fedora audit[1592]: AVC avc: denied { sys_nice } for pid=1592 comm="flatpak" capability=23 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=capability permissive=0 Oct 19 00:59:28 fedora audit[1592]: AVC avc: denied { setsched } for pid=1592 comm="flatpak" scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=process permissive=0 Oct 19 00:59:28 fedora audit[1600]: AVC avc: denied { read write } for pid=1600 comm="gpg" path="/dev/tty1" dev="devtmpfs" ino=20 scontext=system_u:system_r:gpg_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tty_device_t:s0 tclass=chr_file permissive=0 Oct 19 00:59:29 fedora audit[1602]: AVC avc: denied { read write } for pid=1602 comm="gpgsm" path="/dev/tty1" dev="devtmpfs" ino=20 scontext=system_u:system_r:gpg_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tty_device_t:s0 tclass=chr_file permissive=0 Oct 19 00:59:29 fedora audit[1606]: AVC avc: denied { read write } for pid=1606 comm="gpg" path="/dev/tty1" dev="devtmpfs" ino=20 scontext=system_u:system_r:gpg_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tty_device_t:s0 tclass=chr_file permissive=0 Oct 19 00:59:29 fedora audit[1608]: AVC avc: denied { read write } for pid=1608 comm="gpg" path="/dev/tty1" dev="devtmpfs" ino=20 scontext=system_u:system_r:gpg_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tty_device_t:s0 tclass=chr_file permissive=0 Oct 19 00:59:29 fedora audit[1610]: AVC avc: denied { watch } for pid=1610 comm="gpg-agent" path="/tmp/ostree-gpg-kIhRNI" dev="tmpfs" ino=67 scontext=system_u:system_r:gpg_agent_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmp_t:s0 tclass=dir permissive=0 Oct 19 00:59:29 fedora audit[1610]: AVC avc: denied { watch } for pid=1610 comm="gpg-agent" path="/tmp/ostree-gpg-kIhRNI" dev="tmpfs" ino=67 scontext=system_u:system_r:gpg_agent_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmp_t:s0 tclass=dir permissive=0 Oct 19 00:59:29 fedora audit[1616]: AVC avc: denied { read write } for pid=1616 comm="gpg" path="/dev/tty1" dev="devtmpfs" ino=20 scontext=system_u:system_r:gpg_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tty_device_t:s0 tclass=chr_file permissive=0 Oct 19 00:59:29 fedora audit[1618]: AVC avc: denied { read write } for pid=1618 comm="gpg" path="/dev/tty1" dev="devtmpfs" ino=20 scontext=system_u:system_r:gpg_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tty_device_t:s0 tclass=chr_file permissive=0 Oct 19 00:59:29 fedora audit[1620]: AVC avc: denied { read write } for pid=1620 comm="gpg" path="/dev/tty1" dev="devtmpfs" ino=20 scontext=system_u:system_r:gpg_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tty_device_t:s0 tclass=chr_file permissive=0 Oct 19 00:59:29 fedora audit[1622]: AVC avc: denied { read write } for pid=1622 comm="gpg" path="/dev/tty1" dev="devtmpfs" ino=20 scontext=system_u:system_r:gpg_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tty_device_t:s0 tclass=chr_file permissive=0 Oct 19 00:59:29 fedora audit[1622]: AVC avc: denied { open } for pid=1622 comm="gpg" path="/tmp/ostree-gpg-AcTMYo/pubring.gpg" dev="tmpfs" ino=83 scontext=system_u:system_r:gpg_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmp_t:s0 tclass=file permissive=0 Oct 19 00:59:29 fedora audit[1624]: AVC avc: denied { watch } for pid=1624 comm="gpg-agent" path="/tmp/ostree-gpg-AcTMYo" dev="tmpfs" ino=82 scontext=system_u:system_r:gpg_agent_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmp_t:s0 tclass=dir permissive=0 Oct 19 00:59:29 fedora audit[1624]: AVC avc: denied { watch } for pid=1624 comm="gpg-agent" path="/tmp/ostree-gpg-AcTMYo" dev="tmpfs" ino=82 scontext=system_u:system_r:gpg_agent_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmp_t:s0 tclass=dir permissive=0 Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { unlink } for pid=1592 comm="flatpak" name="S.scdaemon" dev="tmpfs" ino=80 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gpg_agent_tmp_t:s0 tclass=sock_file permissive=0 Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { unlink } for pid=1592 comm="flatpak" name="S.scdaemon" dev="tmpfs" ino=97 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gpg_agent_tmp_t:s0 tclass=sock_file permissive=0 Oct 19 00:59:29 fedora flatpak[1592]: system: Added remote flathub to https://dl.flathub.org/repo/ Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { read } for pid=1592 comm="flatpak" name="resolv.conf" dev="vda2" ino=153089 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:net_conf_t:s0 tclass=lnk_file permissive=0 Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { read } for pid=1592 comm="flatpak" name="resolv.conf" dev="vda2" ino=153089 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:net_conf_t:s0 tclass=lnk_file permissive=0 Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { create } for pid=1592 comm=706F6F6C2D666C617470616B207265 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=netlink_route_socket permissive=0 Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { read } for pid=1592 comm=706F6F6C2D666C617470616B207265 name="resolv.conf" dev="vda2" ino=153089 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:net_conf_t:s0 tclass=lnk_file permissive=0 Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { read } for pid=1592 comm=706F6F6C2D666C617470616B207265 name="resolv.conf" dev="vda2" ino=153089 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:net_conf_t:s0 tclass=lnk_file permissive=0 Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { read } for pid=1592 comm=706F6F6C2D666C617470616B207265 name="hosts" dev="vda2" ino=672 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:net_conf_t:s0 tclass=file permissive=0 Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { create } for pid=1592 comm=706F6F6C2D666C617470616B207265 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=udp_socket permissive=0 Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { create } for pid=1592 comm=706F6F6C2D666C617470616B207265 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=udp_socket permissive=0 Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { create } for pid=1592 comm=706F6F6C2D666C617470616B207265 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=udp_socket permissive=0 Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { create } for pid=1592 comm=706F6F6C2D666C617470616B207265 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=udp_socket permissive=0 Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { create } for pid=1592 comm=706F6F6C2D666C617470616B207265 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=udp_socket permissive=0 Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { create } for pid=1592 comm=706F6F6C2D666C617470616B207265 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=udp_socket permissive=0 Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { create } for pid=1592 comm=706F6F6C2D666C617470616B207265 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=udp_socket permissive=0 Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { create } for pid=1592 comm=706F6F6C2D666C617470616B207265 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=udp_socket permissive=0 Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { create } for pid=1592 comm="flatpak" scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=tcp_socket permissive=0 Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { create } for pid=1592 comm="flatpak" scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=tcp_socket permissive=0 Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { create } for pid=1592 comm="flatpak" scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=tcp_socket permissive=0 Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { create } for pid=1592 comm="flatpak" scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=tcp_socket permissive=0 Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { create } for pid=1592 comm="flatpak" scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=tcp_socket permissive=0 Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { create } for pid=1592 comm="flatpak" scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=tcp_socket permissive=0 Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { create } for pid=1592 comm="flatpak" scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=tcp_socket permissive=0 Oct 19 00:59:29 fedora audit[1592]: AVC avc: denied { create } for pid=1592 comm="flatpak" scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tclass=tcp_socket permissive=0 === Sorting through that, we roughly * setsched/sys_nice (bug #1795524) GPG stuff ========= * gpg/gpgsm binaries (launched by gpgme?) trying to open the tty for some reason (logging?) * gpg-agent binary (which we don't need) trying to watch a directory * gpg binary trying to open /tmp/ostree-gpg-AcTMYo/pubring.gpg * flatpak binary trying to unlink created files in /tmp Network stuff (optional post-installation update of remote metadata) ============= * flatpak trying to read networking config files * flatpak trying to do domain name resolution * flatpak using dconf to figure out proxy settings, which uses dbus, etc. This all pulls a lot of string when you start fixing adding permissions, and some of it probably should be suppressed as messages rather than allowed - e.g. flatpak doesn't need to be using dbus-launch to launch a bus as root, so that dconf can talk over the bus, to monitor proxy settings that don't exist I do see that gpg-related files are left over in /tmp, but a bit of addition: ==== allow fedoratp_t gpg_agent_tmp_t:dir read; allow fedoratp_t gpg_agent_tmp_t:sock_file unlink; ==== Didn't fix that. So I'm inclined to say that *for now*, we should just go with the minimal rules above - I don't think cleaning up the audit logs is feasible for F35 GA.
Thanks, Owen. Zdenek, this is now one of the last two blockers for F35 Final, and the other may turn out not to be blocking; it'd be really great if we could get a build with the additional necessary rules today (Tuesday). Thanks a lot!
There is a new scratchbuild available, build on the way: https://koji.fedoraproject.org/koji/taskinfo?taskID=77512984 I am going to test it and create a new one if needed.
Thanks for the quick build. I tested it, and unfortunately, I found that my testing procedure wasn't good enough: * fedora-third-party runs successfully, and stores its state correctly * flathub and dnf repositories are enabled But: === $ flatpak remote-ls flathub error: Unable to load summary from remote flathub: Signature made Tue 19 Oct 2021 08:47:49 AM EDT using RSA key ID 562702E9E3ED7EE8 Can't check signature: public key not found === So, we need to dig into those gpg denials and figure out what is needed. Will work on that now. Sorry for the incomplete information :-((((
I needed the following permissions: === allow fedoratp_t gpg_agent_tmp_t:dir { getattr open read rmdir }; allow fedoratp_t gpg_agent_tmp_t:file { open unlink }; allow gpg_t tmp_t:file { open rename write }; === to a) successfully import the GPG key for the repository b) clean up the directory in /tmp. That leaves the following denials (plus lots of non-logged ones). *Hopefully* they are all harmless. === Oct 19 11:38:32 fedora pkexec[1587]: gnome-initial-setup: Executing command [USER=root] [TTY=unknown] [CWD=/run/gnome-initial-setup/] [COMMAND=/usr/bin/fedora-third-party enable] Oct 19 11:38:32 fedora audit[1590]: AVC avc: denied { write } for pid=1590 comm="flatpak" name="system_bus_socket" dev="tmpfs" ino=1079 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=sock_file permissive=0 Oct 19 11:38:32 fedora audit[1592]: AVC avc: denied { write } for pid=1592 comm="flatpak" name="system_bus_socket" dev="tmpfs" ino=1079 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=sock_file permissive=0 Oct 19 11:38:32 fedora audit[1608]: AVC avc: denied { read write } for pid=1608 comm="gpg-agent" path="/dev/tty1" dev="devtmpfs" ino=20 scontext=system_u:system_r:gpg_agent_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tty_device_t:s0 tclass=chr_file permissive=0 Oct 19 11:38:32 fedora audit[1609]: AVC avc: denied { watch } for pid=1609 comm="gpg-agent" path="/tmp/ostree-gpg-HwXzT9" dev="tmpfs" ino=67 scontext=system_u:system_r:gpg_agent_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmp_t:s0 tclass=dir permissive=0 Oct 19 11:38:32 fedora audit[1609]: AVC avc: denied { watch } for pid=1609 comm="gpg-agent" path="/tmp/ostree-gpg-HwXzT9" dev="tmpfs" ino=67 scontext=system_u:system_r:gpg_agent_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmp_t:s0 tclass=dir permissive=0 Oct 19 11:38:32 fedora audit[1622]: AVC avc: denied { read write } for pid=1622 comm="gpg-agent" path="/dev/tty1" dev="devtmpfs" ino=20 scontext=system_u:system_r:gpg_agent_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tty_device_t:s0 tclass=chr_file permissive=0 Oct 19 11:38:32 fedora audit[1623]: AVC avc: denied { watch } for pid=1623 comm="gpg-agent" path="/tmp/ostree-gpg-kt3R4F" dev="tmpfs" ino=82 scontext=system_u:system_r:gpg_agent_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmp_t:s0 tclass=dir permissive=0 Oct 19 11:38:32 fedora audit[1623]: AVC avc: denied { watch } for pid=1623 comm="gpg-agent" path="/tmp/ostree-gpg-kt3R4F" dev="tmpfs" ino=82 scontext=system_u:system_r:gpg_agent_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmp_t:s0 tclass=dir permissive=0 Oct 19 11:38:32 fedora flatpak[1592]: system: Added remote flathub to https://dl.flathub.org/repo/ Oct 19 11:38:32 fedora audit[1592]: AVC avc: denied { write } for pid=1592 comm="flatpak" name="source" dev="vda2" ino=958 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cert_t:s0 tclass=dir permissive=0 Oct 19 11:38:32 fedora audit[1592]: AVC avc: denied { write } for pid=1592 comm=64636F6E6620776F726B6572 name="system_bus_socket" dev="tmpfs" ino=1079 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=sock_file permissive=0 Oct 19 11:38:32 fedora audit[1592]: AVC avc: denied { name_connect } for pid=1592 comm="flatpak" dest=443 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0 Oct 19 11:38:32 fedora audit[1592]: AVC avc: denied { name_connect } for pid=1592 comm="flatpak" dest=443 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0 Oct 19 11:38:32 fedora audit[1592]: AVC avc: denied { name_connect } for pid=1592 comm="flatpak" dest=443 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0 Oct 19 11:38:32 fedora audit[1592]: AVC avc: denied { name_connect } for pid=1592 comm="flatpak" dest=443 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0 Oct 19 11:38:32 fedora audit[1592]: AVC avc: denied { name_connect } for pid=1592 comm="flatpak" dest=443 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0 Oct 19 11:38:32 fedora audit[1592]: AVC avc: denied { name_connect } for pid=1592 comm="flatpak" dest=443 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0 Oct 19 11:38:32 fedora audit[1592]: AVC avc: denied { name_connect } for pid=1592 comm="flatpak" dest=443 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0 Oct 19 11:38:32 fedora audit[1592]: AVC avc: denied { name_connect } for pid=1592 comm="flatpak" dest=443 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0 === The weird one is: === AVC avc: denied { write } for pid=1592 comm="flatpak" name="source" dev="vda2" ino=958 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cert_t:s0 tclass=dir permissive=0 === That would be easy to permit, but I don't have any idea what code portion is doing that and why :-). It doesn't seem to cause bad effects to deny it. Zdenek: Can you look at what it would take to add the permissions at the top of this comment? The gpg_t one might be a little trickier, but I hope you have ideas how to handle it :-) Thanks!
After a few iteration there is a new scratchbuild: https://koji.fedoraproject.org/koji/taskinfo?taskID=77525712 I am curious how others now see the result as the AVCs on my systems are sometimes different. The source directory is /etc/pki/ca-trust/source/. Also note I used https://dl.fedoraproject.org/pub/fedora/linux/development/35/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-35-20211019.n.0.iso and the chcon is still there.
Yeah, we didn't push the fedora-third-party build with the chcon removal stable as it didn't solve the problem. If it would still *help*, we can push both it and an selinux-policy build stable, if we can hit on a combination that we like...
> Yeah, we didn't push the fedora-third-party build with the chcon removal stable as it didn't solve the problem. If it would still *help*, we can push both it and an selinux-policy build stable, if we can hit on a combination that we like... Sorry that wasn't clear - we need *both*. Will test Zdenek's new scratchbuild now (on top of the fedora-third-party change.)
$ flatpak remote-ls flathub Name Application ID Version Branch desktop com.bitwarden.desktop stable Postman com.getpostman.Postman stable Teams com.microsoft.Teams stable Minecraft com.mojang.Minecraft stable Client com.skype.Client stable Zoom us.zoom.Zoom stable i386 org.freedesktop.Platform.Compat.i386 20.08 i386 org.freedesktop.Platform.Compat.i386 21.08 x86_64 org.freedesktop.Platform.Compat.x86_64 20.08 x86_64 org.freedesktop.Platform.Compat.x86_64 21.08 default org.freedesktop.Platform.GL.default 20.08 default org.freedesktop.Platform.GL.default 21.08 default org.freedesktop.Platform.GL32.default 20.08 default org.freedesktop.Platform.GL32.default 21.08 freedesktop platform org.freedesktop.Platform 20.08 freedesktop platform org.freedesktop.Platform 21.08 aarch64 org.freedesktop.Sdk.Compat.aarch64 20.08 aarch64 org.freedesktop.Sdk.Compat.aarch64 21.08 i386 org.freedesktop.Sdk.Compat.i386 20.08 i386 org.freedesktop.Sdk.Compat.i386 21.08 x86_64 org.freedesktop.Sdk.Compat.x86_64 20.08 x86_64 org.freedesktop.Sdk.Compat.x86_64 21.08 freedesktop development platform docs org.freedesktop.Sdk.Docs 20.08 freedesktop development platform docs org.freedesktop.Sdk.Docs 21.08 freedesktop development platform org.freedesktop.Sdk 20.08 freedesktop development platform org.freedesktop.Sdk These denials are still reported: ---- type=PROCTITLE msg=audit(10/19/21 16:00:46.895:256) : proctitle=flatpak remotes --system --columns=name,filter type=PATH msg=audit(10/19/21 16:00:46.895:256) : item=0 name=/var/run/dbus/system_bus_socket inode=1121 dev=00:1a mode=socket,666 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:system_dbusd_var_run_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(10/19/21 16:00:46.895:256) : cwd=/root type=SOCKADDR msg=audit(10/19/21 16:00:46.895:256) : saddr={ saddr_fam=local path=/var/run/dbus/system_bus_socket } type=SYSCALL msg=audit(10/19/21 16:00:46.895:256) : arch=x86_64 syscall=connect success=no exit=EACCES(Permission denied) a0=0x5 a1=0x7ffd29bacd20 a2=0x6e a3=0x0 items=1 ppid=1526 pid=1529 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=tty1 ses=unset comm=flatpak exe=/usr/bin/flatpak subj=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(10/19/21 16:00:46.895:256) : avc: denied { write } for pid=1529 comm=flatpak name=system_bus_socket dev="tmpfs" ino=1121 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=sock_file permissive=0 ---- type=PROCTITLE msg=audit(10/19/21 16:00:46.907:257) : proctitle=flatpak remote-add --from flathub /usr/lib/fedora-third-party/conf.d/fedora-flathub.flatpakrepo type=PATH msg=audit(10/19/21 16:00:46.907:257) : item=0 name=/var/run/dbus/system_bus_socket inode=1121 dev=00:1a mode=socket,666 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:system_dbusd_var_run_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(10/19/21 16:00:46.907:257) : cwd=/root type=SOCKADDR msg=audit(10/19/21 16:00:46.907:257) : saddr={ saddr_fam=local path=/var/run/dbus/system_bus_socket } type=SYSCALL msg=audit(10/19/21 16:00:46.907:257) : arch=x86_64 syscall=connect success=no exit=EACCES(Permission denied) a0=0x5 a1=0x7ffc86e77bb0 a2=0x6e a3=0x0 items=1 ppid=1526 pid=1531 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=tty1 ses=unset comm=flatpak exe=/usr/bin/flatpak subj=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(10/19/21 16:00:46.907:257) : avc: denied { write } for pid=1531 comm=flatpak name=system_bus_socket dev="tmpfs" ino=1121 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=sock_file permissive=0 ---- type=PROCTITLE msg=audit(10/19/21 16:00:46.996:258) : proctitle=flatpak remote-add --from flathub /usr/lib/fedora-third-party/conf.d/fedora-flathub.flatpakrepo type=MMAP msg=audit(10/19/21 16:00:46.996:258) : fd=6 flags=MAP_SHARED type=SYSCALL msg=audit(10/19/21 16:00:46.996:258) : arch=x86_64 syscall=mmap success=no exit=EACCES(Permission denied) a0=0x0 a1=0x1 a2=PROT_READ a3=MAP_SHARED items=0 ppid=1526 pid=1531 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=tty1 ses=unset comm=flatpak exe=/usr/bin/flatpak subj=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(10/19/21 16:00:46.996:258) : avc: denied { map } for pid=1531 comm=flatpak path=/root/.cache/dconf/user dev="vda2" ino=160460 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cache_home_t:s0 tclass=file permissive=0 but do not seem to have effect on flatpak.
Let me try to document my testing procedures in detail to put control more in Zdenek's hands. === Setup === Install a recent fedora image Before rebooting into the system, chroot in the live image and A) Set a root password B) Install the latest fedoro-third-party build: https://koji.fedoraproject.org/koji/buildinfo?buildID=1845672 C) Install a recent policy build like: https://koji.fedoraproject.org/koji/taskinfo?taskID=77525712 ============= [ B) and C) are optional - you can always update these later ] === reset.sh Helper script === #!/usr/bin/bash fedora-third-party disable flatpak remote-delete flathub rm /var/lib/fedora-third-party/state ============= === Full test inside gnome-initial-setup === ./reset.sh # ignore errors about missing flathub remote systemctl rescue userdel -r -d <testuser> systemctl reboot < go through gnome-initial-setup > ==== === Fast test ==== setsebool daemons_use_tty 1 # once, after a reboot, to get log messages semodule -DB # optional, if dontaudits seem to be the problem ./reset.sh date=$(date +%X) runcon system_u:system_r:fedoratp_t:s0-s0:c0.c1023 fedora-third-party enable ausearch -ts "$date" --raw semodule -B # turn dontaudits back off ==== === Verification procedure ==== A) Examine /etc/yum.repos.d/google-chrome.repo - should have enabled=1 B) Check 'flatpak remotes' - flathub should be included C) Try 'flatpak remote-ls flathub' - should list applications D) Examine /var/lib/fedora-third-party - should have, among other things: [flathub] added = yes seen = yes [google-chrome] seen = yes ==== With the latest selinux-policy build, my "fast test" procedure is dying with === dconf:ERROR:../shm/dconf-shm.c:93:dconf_shm_open: assertion failed: (memory != MAP_FAILED) Bail out! dconf:ERROR:../shm/dconf-shm.c:93:dconf_shm_open: assertion failed: (memory != MAP_FAILED) Traceback (most recent call last): File "/usr/bin/fedora-third-party", line 33, in <module> sys.exit(load_entry_point('fedora-third-party==0.8', 'console_scripts', 'fedora-third-party')()) File "/usr/lib/python3.10/site-packages/click/core.py", line 1137, in __call__ return self.main(*args, **kwargs) File "/usr/lib/python3.10/site-packages/click/core.py", line 1062, in main rv = self.invoke(ctx) File "/usr/lib/python3.10/site-packages/click/core.py", line 1668, in invoke return _process_result(sub_ctx.command.invoke(sub_ctx)) File "/usr/lib/python3.10/site-packages/click/core.py", line 1404, in invoke return ctx.invoke(self.callback, **ctx.params) File "/usr/lib/python3.10/site-packages/click/core.py", line 763, in invoke return __callback(*args, **kwargs) File "/usr/lib/python3.10/site-packages/click/decorators.py", line 84, in new_func return ctx.invoke(f, obj, *args, **kwargs) File "/usr/lib/python3.10/site-packages/click/core.py", line 763, in invoke return __callback(*args, **kwargs) File "/usr/lib/python3.10/site-packages/fedora_third_party/cli.py", line 42, in enable repository.enable() File "/usr/lib/python3.10/site-packages/fedora_third_party/repository.py", line 107, in enable self.run_flatpak(['remote-add', '--from', self.name, self.flatpakrepo]) File "/usr/lib/python3.10/site-packages/fedora_third_party/repository.py", line 103, in run_flatpak subprocess.check_call(command) File "/usr/lib64/python3.10/subprocess.py", line 369, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['flatpak', 'remote-add', '--from', 'flathub', '/usr/lib/fedora-third-party/conf.d/fedora-flathub.flatpakrepo']' died with <Signals.SIGABRT: 6>. === But maybe the gnome-initial-setup environment setup is different enough that this dconf error isn't occurring. Let me try that.
I also get the same crash if I remove /root/.cache and try the full procedure. The failure here does leave 'flatpak remote-ls' working, so I think you (Zdenek) just didn't notice the crash. (The avc for it is in what you showed as a residual avc: denied { map } for pid=1531 comm=flatpak path=/root/.cache/dconf/user dev="vda2" ino=160460 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cache_home_t:s0 tclass=file permissive=0. The other check is to just search for fedora-third-party in journalctl -B - if it is crashing/failing gnome-initial-setup will log the exit code, and there may also be messages from ABRT. (But no backtrace or other stderr output, because selinux is preventing that in some fashion.)
OK, adding === # This fixes the crash allow fedoratp_t cache_home_t:file map; # This shows up afterwards, but is not stricly necessary - I think flatpak/ostree/glib is probably falling back from mmap to read allow fedoratp_t var_lib_t:file map; === gets me to something that seems to fully work. The remaining audited avcs are: === Oct 19 16:53:24 fedora pkexec[1588]: gnome-initial-setup: Executing command [USER=root] [TTY=unknown] [CWD=/run/gnome-initial-setup/] [COMMAND=/usr/bin/fedora-third-party enable] Oct 19 16:53:24 fedora audit[1591]: AVC avc: denied { write } for pid=1591 comm="flatpak" name="system_bus_socket" dev="tmpfs" ino=1068 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=sock_file permissive=0 Oct 19 16:53:24 fedora audit[1593]: AVC avc: denied { write } for pid=1593 comm="flatpak" name="system_bus_socket" dev="tmpfs" ino=1068 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=sock_file permissive=0 Oct 19 16:53:25 fedora flatpak[1593]: system: Added remote flathub to https://dl.flathub.org/repo/ Oct 19 16:53:25 fedora audit[1593]: AVC avc: denied { write } for pid=1593 comm=64636F6E6620776F726B6572 name="system_bus_socket" dev="tmpfs" ino=1068 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=sock_file permissive=0 Oct 19 16:53:25 fedora flatpak[1593]: system: Modified remote flathub to https://dl.flathub.org/repo/O ==
So another scratchbuild: https://koji.fedoraproject.org/koji/taskinfo?taskID=77534473
Zdenek: if you could just YOLO a *real* build I'd really appreciate it, as we could then fire an RC. We have at least *tentative* fixes for everything that's definitely a blocker at this point. It doesn't need to go stable, just needs to be in updates-testing. Thanks! I will build a live image with the scratch build and the latest fedora-third-party build in the meantime and see how that goes.
With the scratch build and the latest fedora-third-party build, this works fully for me. Remaining messages are: ==== Oct 19 19:23:44 fedora pkexec[1589]: gnome-initial-setup: Executing command [USER=root] [TTY=unknown] [CWD=/run/gnome-initial-setup/] [COMMAND=/usr/bin/fedora-third-party enable] Oct 19 19:23:45 fedora audit[1592]: AVC avc: denied { write } for pid=1592 comm="flatpak" name="system_bus_socket" dev="tmpfs" ino=1063 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_dbusd_var_r> Oct 19 19:23:45 fedora audit[1594]: AVC avc: denied { write } for pid=1594 comm="flatpak" name="system_bus_socket" dev="tmpfs" ino=1063 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_dbusd_var_r> Oct 19 19:23:45 fedora flatpak[1594]: system: Added remote flathub to https://dl.flathub.org/repo/ Oct 19 19:23:45 fedora audit[1594]: AVC avc: denied { write } for pid=1594 comm=64636F6E6620776F726B6572 name="system_bus_socket" dev="tmpfs" ino=1063 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sys> Oct 19 19:23:45 fedora audit[1594]: AVC avc: denied { map } for pid=1594 comm="flatpak" path="/var/lib/flatpak/repo/tmp/cache/summaries/flathub-x86_64-feee169ff2eb73e5af3b569754f34da48d07139be1d7afcb342b6a0a95ac30d3.sub" dev="vda2" in> ==== I do think the last one is better fixed (allow fedoratp_t var_lib_t:file map), but does not need to be fixed for GA. Let's get a real build in place so things can move forward!
(In reply to Adam Williamson from comment #81) > Zdenek: if you could just YOLO a *real* build I'd really appreciate it, as > we could then fire an RC. We have at least *tentative* fixes for everything > that's definitely a blocker at this point. It doesn't need to go stable, > just needs to be in updates-testing. Thanks! > > I will build a live image with the scratch build and the latest > fedora-third-party build in the meantime and see how that goes. Builds need to go through CI so it takes more time, but they are always initiated. The content is then the same as the latest scratchbuild.
ah OK, wasn't aware of that. Great. So it should show up soon, I guess. My test live image is building ATM to confirm Owen's finding.
OK, confirmed Owen's results with the live image, i.e., things actually work! After install I can find Chrome and the NVIDIA driver. No sign of an official build appearing, though? I don't know where to look for this CI run we're allegedly waiting on?
Tested with Fedora-Workstation-Live-x86_64-35-1.1.iso. Both RPM and flatpak repos got enabled correctly, yay! Unfortunately, gnome-software doesn't display Nvidia driver nor Steam, even if you wait a long time. I believe this is another case of bug 2010740. Gnome-software/PackageKit are not informed that they should refresh the repos, after they are enabled by fedora-third-party. Unfortunately opening and closing the Software Repositories dialog in GS doesn't help either, because GS only triggers repo refresh if you do some changes in that dialog (I assume). So you need to toggle some repos off an on again, or you need to force GS to look for updates, otherwise Nvidia and Steam will only get visible after a day or so, when GS/PK decide to refresh repos. I guess the proper solution here is that fedora-third-party should run "pkcon refresh force" at the end of its script. Or somehow notify GS to refresh its repos. Should I file a separate bug for this?
I also tested this and can confirm that the described functionality works. I am not sure if I can reproduce the Steam problem, because I am seeing the Steam application available for installation (see screenshot). However, I have not been using Steam or Nvidia, so I am not sure what to expect.
Created attachment 1835017 [details] Steam is available in Software
Good news is that it's not completely broken. I made a snapshot of my VM directly after install, and then performed many roundtrips of boot the system -> enable 3rd party repos in g-i-s -> start gnome-software -> search "steam" -> revert VM snapshot and repeat. I can see steam and nvidia in some attempts, same as Lukas. But in at least 50% of cases, the results are not there. There is either some race condition, or it is caused by some repo mirror which times out/fails and PK doesn't recover (I tried waiting 15 more minutes, no help). Unfortunately neither PackageKit nor gnome-software provide debug logs by default anywhere, so I can't easily confirm that theory :-/ If I hammer random mirrors though dnf, they seem to be working well enough.
Kamil, Do you see any AVC denials with matching time of the attempts?
It's very likely that bug #2010740 is not fully fixed. This issue is fixed because the repos are enabled as expected.
Created attachment 1835106 [details] journal after not finding steam+nvidia (In reply to Zdenek Pytela from comment #91) > Do you see any AVC denials with matching time of the attempts? I only see AVCs from gnome-initial-setup: Oct 20 15:27:42 fedora pkexec[1552]: gnome-initial-setup: Executing command [USER=root] [TTY=unknown] [CWD=/run/gnome-initial-setup/] [COMMAND=/usr/bin/fedora-third-party enable] Oct 20 15:27:42 fedora audit[1555]: AVC avc: denied { write } for pid=1555 comm="flatpak" name="system_bus_socket" dev="tmpfs" ino=1092 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=sock_file permissive=0 Oct 20 15:27:42 fedora audit[1557]: AVC avc: denied { write } for pid=1557 comm="flatpak" name="system_bus_socket" dev="tmpfs" ino=1092 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=sock_file permissive=0 Oct 20 15:27:42 fedora flatpak[1557]: system: Added remote flathub to https://dl.flathub.org/repo/ Oct 20 15:27:42 fedora audit[1557]: AVC avc: denied { write } for pid=1557 comm=64636F6E6620776F726B6572 name="system_bus_socket" dev="tmpfs" ino=1092 scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=sock_file permissive=0 Oct 20 15:27:43 fedora flatpak[1557]: system: Modified remote flathub to https://dl.flathub.org/repo/ After I'm logged into the user session and use gnome-software to search, I don't see any AVCs there.
*** Bug 2003158 has been marked as a duplicate of this bug. ***
*** Bug 2007075 has been marked as a duplicate of this bug. ***
*** Bug 2013378 has been marked as a duplicate of this bug. ***
Zdenek, sorry for stepping on your toes a bit with the build, we really needed to get the RC built and I didn't know how long it'd take for the 35.4-1 build to happen so I had to do something :) Hope it didn't mess anything up too bad.
(In reply to Adam Williamson from comment #97) > Zdenek, sorry for stepping on your toes a bit with the build, we really > needed to get the RC built and I didn't know how long it'd take for the > 35.4-1 build to happen so I had to do something :) Hope it didn't mess > anything up too bad. Frankly it took me some time to figure out what had happened when I tried to create the build and did not succeed. It's ok now, I created a build with some minor changes, but not the update as I am not sure if it could make any further mess with preparing the Fedora image.
Ah, sorry again. It's fine to create an update, it won't mess with anything (we can still push the update that was included in RC1 stable if we decide to release RC1).
(In reply to Michael Catanzaro from comment #92) > It's very likely that bug #2010740 is not fully fixed. > > This issue is fixed because the repos are enabled as expected. I agree.
I re-opened https://bugzilla.redhat.com/show_bug.cgi?id=2010740 , for discussion of that problem.
(In reply to Kamil Páral from comment #87) > I guess the proper solution here is that fedora-third-party should run > "pkcon refresh force" at the end of its script. Or somehow notify GS to > refresh its repos. I agree with this. The gnome-software has no chance to know that certain repos changed from the outside (I write 'certain', because the flatpak backend can notice such changes, but the PackageKit cannot). The fedora-third-party should update the repo data when it enables some repos on its own. That's the packagekit command above for the PackageKit repos and the following command for the flatpak repos: $ flatpak update --appstream
"I agree with this. The gnome-software has no chance to know that certain repos changed from the outside (I write 'certain', because the flatpak backend can notice such changes, but the PackageKit cannot)." Well, uh, hold on. That doesn't seem like really the timing, here? Remember, when g-i-s runs in this scenario, *we don't have a user account at all*. The gnome-software that will eventually run as part of our first user's session is certainly not running yet, because that user doesn't even exist yet. g-i-s runs and does everything it does - enabling third-party repos included - before we ever start a session for that user. Your description above reads like g-i-s is enabling repos kinda "behind gnome-software's back", but that doesn't really seem to be what's going on? The gnome-software that runs in the first user's session should never even know that the third party repos had ever been *dis*abled, should it? By the time it runs, they're already enabled... There's a systemwide packagekit service that's presumably running when g-i-s runs...should that service know that the repo config has changed, and that the metadata should be refreshed?
I've played with this a lot this morning. Each time when I don't see steam/nvidia in gnome-software, I *can* find them though packagekit itself! I.e. using: $ pkcon search Steam | grep rpmfusion # mind the capital S, it's needed $ pkcon search nvidia | grep rpmfusion So good news, this is not a repo mirror problem. This is our problem. Also, I made numerous boots where I added systemd.debug-shell to the kernel params, booted into g-i-s, configured everything including third-party repos, then stayed at the very last page, switched to the debug shell at TTY9, started "pkcon refresh force" (didn't wait for finish), switched back to g-i-s, completed it, started gnome-software, and searched for steam+nvidia. In each attempt, steam and nvidia could be found. So "pkcon refresh force" during g-i-s definitely solves this problem. ---- I also tried to dig deeper into packagekit. If you don't enable 3rd party repos in g-i-s, start pkmon and wait for operations to settle, and then execute "sudo fedora-third-party -v enable", you'll see in pkmon only multiple lines saying: > repo-list-changed So PK detects the repo change, but doesn't automatically refreshes its repos. However, it does automatically refresh the repos once you run "pkcon search" (also visible in pkmon), and steam+nvidia are immediately present in this first search. *However*, at this point, gnome-software still doesn't know about steam/nvidia, even though PK does. Even if you restart gnome-software using "gnome-software --quit" (or pkill), steam+nvidia doesn't appear. ---- I still don't understand why the behavior is erratic. But this seems to be a problem somewhere between PK and gnome-software. PK is always aware of the new packages, gnome-software only sometimes. "pkcon refresh force" during g-i-s seems to solve this every time.
(In reply to Adam Williamson from comment #104) > Well, uh, hold on. That doesn't seem like really the timing, here? Right, I meant when the repo setup is changed while gnome-software is running. That's not the case with the initial setup, as you said. If I'm not mistaken, the things should work this way: - user logs in for the first time; - gnome-software runs for the first time, which means it downloads repo data after start - that's happening before the page with the applications is shown (the overview page, aka the Explore tab); - the gnome-software should provide the users with the applications from all the enabled repos If that fails, then something is wrong. The gnome-software reads the app data from the appstream bits. Those are saved in /var/cache/app-info/xmls/ by the PackageKit. There should be shown rpmfusion-nonfree-steam.xml and rpmfusion-nonfree-nvidia-driver.xml, for the two named repos. I do not think PacakgeKit itself uses this appstream data for its search, but I do not know that for sure. If the files are on their place, then maybe this is related to: https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1422 The gnome-software's gnome-41 branch contains a lot of changes, which can be related. Pick only some of those proves to be tricky. I made a scratch build of the gnome-software with the snapshot at commit c10f4fd7dcd84c0a75d6777d8883278284ec6962 and with only added patch being for the issue 1422 mentioned above. If anyone wants to give it a try, then it can be downloaded here: https://koji.fedoraproject.org/koji/taskinfo?taskID=77613497
> and with only added patch being for the issue 1422 mentioned above. Err, wrong, the only added patch is for this https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/1024 (update after repo changes, as approved by the upstream).
> The gnome-software reads the app data from the appstream bits. Those are saved in /var/cache/app-info/xmls/ by the PackageKit. There should be shown rpmfusion-nonfree-steam.xml and rpmfusion-nonfree-nvidia-driver.xml, for the two named repos. I do not think PacakgeKit itself uses this appstream data for its search, but I do not know that for sure. If the packages are missing from gnome-software on first-boot, then /var/cache/app-info/xmls/ is *empty*. The repos are enabled (visible in `pkcon repo-list`), and the packages can be searched through `pkcon search`, but the dir stays empty. Only when running `pkcon refresh force`, then the xmls are saved in there. If the packages show up in gnome-software search on first-boot, then /var/cache/app-info/xmls/ contains the xmls. So if gnome-software relies on those xmls in that location, something is not creating them there (very often - I just did 10 attempts, and it worked as expected only *once*).
Kamile, Do you have any indication this can be resolved in selinux-policy, e. g. in SELinux permissive mode the same scenario works?
(In reply to Zdenek Pytela from comment #109) > Do you have any indication this can be resolved in selinux-policy, e. g. in > SELinux permissive mode the same scenario works? I don't think so. I just booted with enforcing=0 and still reproduced the problem. Moving back to fedora-third-party.
So, the initial bug here is fixed, really. fedora-third-party does indeed enable the repositories now. I think it makes most sense to track the new problem as a new bug, so I filed it: https://bugzilla.redhat.com/show_bug.cgi?id=2016510 and transferred the accepted blocker status there. I think we can close *this* bug when https://bodhi.fedoraproject.org/updates/FEDORA-2021-d3cb1609c8 goes stable.
FEDORA-2021-d3cb1609c8 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.