Newly populated private volumes don’t get proper SELinux labels

[SiGraphics]

How to file a helpful issue

Qubes OS release

R4.2.0-rc1 (and most recent 4.2 weekly build)

Brief summary

[sys-net] Connection Failure

Failed to add/activate connection

failure adding connection: error writing to file ‘/etc/NetworkManager/system-connections/{wireless name}.nmconnection’: failed to create file /etc/NetworkManager/system-connections/{wireless name}.nmconnection.46E551: Permission denied

Steps to reproduce

Install R4.2.0-rc1
Attempt to use WiFi

Expected behavior

WiFi works

Actual behavior

WiFi doesn't work

Don’t have access to a LAN connection, so unable to test.

[syntheticdrek]

This seems to be caused by selinux contexts not persisting in /rw when sys-net is based on a Fedora 38 disposable. A simple sudo restorecon -vrF /rw in sys-net resolves it in my testing. It appears that a sys-net based on non-disposable fedora-38 or a disposable debian-11 isn't affected.

[tlaurion]

@marmarek how to fix this on fedora38 based templates so disp sys-net can be used?

[DemiMarie]

@tlaurion Looks like a missing relabel after populating /rw.

[tlaurion]

@DemiMarie still not fixed in weekly iso? To be clear, solution provided by #8242 (comment) works on dispvm, but template is the problem. Template should be fixed.

Lack of replies here only means people are not enabling disp sys-net with fedora at install.

[tlaurion]

It appears that a sys-net based on non-disposable fedora-38 or a disposable debian-11 isn't affected.

Ditching fedora for debian for service dispvms for now to test further Q4.2 without the annoyances on weekly isos.

[DemiMarie]

All options offered by the installer should work out of the box. Marking as blocker.

[tlaurion]

@marmarek

https://openqa.qubes-os.org/tests/80558/asset/iso/Qubes-4.2.202308242042-x86_64.iso

Still affected :(

[tlaurion]

@andrewdavidwong package is in the testing repo but not in test ISO's templates (weekly or openqa's) This is a corner case of "please update" that is not possible easily.

We can conclude that testers are not using dispvm sys-net over fedora still today.

[andrewdavidwong]

We can conclude that testers are not using dispvm sys-net over fedora still today.

Well, it looks like this was also reported in #8445, so perhaps that is not entirely true.

[DemiMarie]

We can conclude that testers are not using dispvm sys-net over fedora still today.

Well, it looks like this was also reported in #8445, so perhaps that is not entirely true.

This problem breaks updates, so it needs to be fixed via a new ISO and a new template image. @marmarek can you make sure that updated templates are available before rc2?

[Augsch123]

I'm using disposable sys-net. But I have a different setup. I have a sys-net-dvm which is an app qube as the disposable template, and a sys-net which is a disposable.

I also got the same error as shown in tlaurion's screenshot when I had changed my sys-net-dvm's template qube to fedora-38 and was trying to boot up sys-net. I guessed this had to do with disposable, so I booted up sys-net-dvm and connected to wifi there. Then I shut down sys-net-dvm and booted sys-net, and the error went away, so I didn't report this to the issue tracker.

[DemiMarie]

Does this problem impact anyone whose ISO includes QubesOS/qubes-core-agent-linux#437?

[tlaurion]

Does this problem impact anyone whose ISO includes QubesOS/qubes-core-agent-linux#437?

@DemiMarie What ISO are you referring to? Short version: This issue was closed but not fixed in templates or ISOs. Testers expect ISOs to work. The openqa ISOs and the weekly ISOs do not have updated templates containing updated package. The last ‘weekly’ iso is from August 8th. Today's openqa build might contain the fix but I'm not sure.

TLDR: Bug in fedora template installation with dispvm service VMs and sys-net. Closed but not fixed. Testers confused. Testing processes unclear. Need discussion on forum.

Possible solution: Add an installer issue tag that will trigger template rebuilds when a package that fixes an installer issue is built, so that the next openqa/weekly builds create ISOs that include the templates containing the fix? Even better: CI building templates hooking back to pr and/or back to issue to point which iso to test for an installer fix.

[marmarek]

Does this problem impact anyone whose ISO includes QubesOS/qubes-core-agent-linux#437?

Probably no, but nobody tried because such ISO does not exist (yet). Fedora templates (until yesterday) were built before the fix was pushed, so any ISO did not include it. That's the whole confusion @tlaurion is talking about.
I think the simple improvement to the process would be to build templates more often (every week? every two weeks?).

[tlaurion]

Does this problem impact anyone whose ISO includes QubesOS/qubes-core-agent-linux#437?

Probably no, but nobody tried because such ISO does not exist (yet). Fedora templates (until yesterday) were built before the fix was pushed, so any ISO did not include it. That's the whole confusion @tlaurion is talking about.
I think the simple improvement to the process would be to build templates more often (every week? every two weeks?).

Edited: moved this discussion unrelated to this issue to #8449

[samtinel]

I don't fully understand if feedback is still asked for here, but updating qubes-core-agent to testing fixed it for me.

[andrewdavidwong]

This issue has been closed as resolved. If anyone believes this issue is not yet resolved, or if anyone is still affected by this issue, please leave a comment, and we'll be happy to reopen it. Thank you.