Bugzilla – Bug 1227344
MicroOS Cockpit SELinux Application missing from menu on non-SELinux enabled system
Last modified: 2024-07-08 09:25:05 UTC
Created attachment 875848 [details] Overview I do not recall when the SELinux and Storage Applications vanished form the Cockpit menu, but it's been several updates since. If one clicks on Applications, Cockpit lists the installed Applications, and SELinux and Storage are present, but on drilling down in to either of them, a Not Found error screen is returned. NAME="openSUSE MicroOS" # VERSION="20240629" ID="opensuse-microos" ID_LIKE="suse opensuse opensuse-tumbleweed microos sl-micro" VERSION_ID="20240629" PRETTY_NAME="openSUSE MicroOS" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:microos:20240629" BUG_REPORT_URL="https://bugzilla.opensuse.org" SUPPORT_URL="https://bugs.opensuse.org" HOME_URL="https://www.opensuse.org/" DOCUMENTATION_URL="https://en.opensuse.org/Portal:MicroOS" LOGO="distributor-logo-MicroOS"
Created attachment 875849 [details] Applications screen
Created attachment 875850 [details] Error screen
For missing Storage I'd guess it's a duplicate of https://bugzilla.suse.com/show_bug.cgi?id=1227299 That doesn't seem to be the same problem for the cockpit-selinux module, however. @Alice: another magically disappearing module. I'm not using SELinux there but can duplicate on regular Tumbleweed as well. Installed but it's missing from the menu.
Found this in the logs menu... not sure it's related, but... /usr/bin/cockpit-bridge /usr/share/cockpit/storaged/manifest.json: Expecting ',' delimiter: line 31 column 22 (char 1213) CODE_ARGS (PosixPath('/usr/share/cockpit/storaged/manifest.json'), JSONDecodeError("Expecting ',' delimiter: line 31 column 22 (char 1213)")) CODE_FILE /usr/lib/python3.11/site-packages/cockpit/packages.py CODE_FUNC load_manifests CODE_LINE 400 LOGGER cockpit.packages PRIORITY 3 PROCESS_NAME MainProcess SYSLOG_IDENTIFIER /usr/bin/cockpit-bridge THREAD_NAME MainThread _AUDIT_LOGINUID 0 _AUDIT_SESSION 3 _BOOT_ID 7019abb989b2471bbfa302eaf6bb5164 _CAP_EFFECTIVE 1ffffffffff _CMDLINE /usr/bin/python3 /usr/bin/cockpit-bridge _COMM cockpit-bridge _EXE /usr/bin/python3.11 _GID 0 _HOSTNAME rpi3 _MACHINE_ID 5c963d6688c141df9207e17b3a984d50 _PID 6461 _RUNTIME_SCOPE system _SOURCE_REALTIME_TIMESTAMP 1720010301065643 _SYSTEMD_CGROUP /user.slice/user-0.slice/session-3.scope _SYSTEMD_INVOCATION_ID 819d083c2e3541a88cff68a98b81ecd7 _SYSTEMD_OWNER_UID 0 _SYSTEMD_SESSION 3 _SYSTEMD_SLICE user-0.slice _SYSTEMD_UNIT session-3.scope _SYSTEMD_USER_SLICE -.slice _TRANSPORT journal _UID 0 __CURSOR s=0f5e08de4b4947e49c421727a8a58884;i=50fcb1;b=7019abb989b2471bbfa302eaf6bb5164;m=13f455e3ac;t=61c571b014a0c;x=b0a3445c98233a58 __MONOTONIC_TIMESTAMP 85703648172 __REALTIME_TIMESTAMP 1720010301065740 __SEQNUM 5307569 __SEQNUM_ID 0f5e08de4b4947e49c421727a8a58884
Created attachment 875853 [details] supportconfig In case it helps...
So as Robert Simai said the storage section not showing is in progress currently as part of a separate bug report As for selinux not showing, I've had a dig into this and looking at the supportconfig you sent over, selinux is disabled. The Cockpit module checks for the existence of the path `/sys/fs/selinux`, if this path doesn't exist on the system we don't show the Cockpit's selinux module since it's disabled so this is intended behavior
duplicate *** This bug has been marked as a duplicate of bug 1227299 ***
Reopen for the selinux part. Is there any chance we can output a more meaningful message? You'll easily run into this situation when you install the selinux module because you need it to admin another host from this instance. Similar to e.g. the podman module that checks if the podman service is running and tells the user.
(In reply to Robert Simai from comment #8) > You'll easily run into this situation when you install > the selinux module because you need it to admin another host from this > instance. I guess that's nonsense as the module needs to be installed on the target system. Nonetheless, I wonder if we can output a more meaningful message.
Hmm it's a difficult one. If you look at it from a systems management point of view, the correct behavior is to not show it on a system that doesn't have Selinux enabled. Since what are you going to be managing there I've double checked and if you network two systems, one with Selinux and one without, this behavior works fine. Selinux is shown on the system that does have it while on the original system it is hidden since Selinux is disabled or not installed I don't think a message in the style of Podman's "Service not running" would work particularly well, since Podman's is easily recoverable. Whereas Selinux's setup can be a lot more specific system wise and a bit more hands on. I'd suggest adding a message against the application in the apps screen however, a little note specifying that it's not in use for this system as Selinux is not enabled potentially with a link to the distributions documentation. That way it could also easily cover other apps that find themself in a similar position, this would require cockpit-packagekit to be installed however I'm open to thoughts on my proposal
My apologies, there appears to be something wrong with my system where this is happening... "selinux" doe sin fact return "Disabled", however, in the /etc/selinux/config, the setting "SELINUX=enforcing" is present, so I'm not sure why selinux is disabled. I'll dig in to that now and let you know if the SELinux menu comes back once fixed.
(In reply to Alice Brooks from comment #10) > I'd suggest adding a message against the application in the apps screen > however, a little note specifying that it's not in use for this system as > Selinux is not enabled potentially with a link to the distributions > documentation. That way it could also easily cover other apps that find > themself in a similar position, this would require cockpit-packagekit to be > installed however > > I'm open to thoughts on my proposal I guess you're right, it makes sense to add a note under Applications as this is the only link to the purposely hidden page. Or we leave it as it is. We could also think about adding it to the docs but I didn't find anything useful in the upstream docs for this module, and ours only refers to SLE Micro where a Tumbleweed user wouldn't look.
I found "selinux=0" set in /etc/default/grub. I must have been doing some troubleshooting a while back and not recalled that I'd disabled SELinux. After re-enabling SELinux in grub and rebooting, the system fails to boot... I'm investigating... but you can probably close this bug as I imagine whatever's wrong is unrelated to Cockpit.
Problem solved, SELinux enabled, and the SELinux menu now appears in Cockpit and I can drill down in to it as expected.
> Problem solved, SELinux enabled, and the SELinux menu now appears in Cockpit and I can drill down in to it as expected. Awesome glad we were able to help! > I guess you're right, it makes sense to add a note under Applications as this > is the only link to the purposely hidden page. Or we leave it as it is. > > We could also think about adding it to the docs but I didn't find anything > useful in the upstream docs for this module, and ours only refers to SLE Micro > where a Tumbleweed user wouldn't look. I think doing both would be beneficial, if nothing else it at least it's documented somewhere
Hi Jana. Could we add a little note under https://documentation.suse.com/sle-micro/6.0/html/Micro-6.0-cockpit/index.html#concept-SELinux to outline that the selinux module only appears if selinux was enabled at boot time, else it's hidden?
(In reply to Robert Simai from comment #16) > Hi Jana. Could we add a little note under > > https://documentation.suse.com/sle-micro/6.0/html/Micro-6.0-cockpit/index. > html#concept-SELinux > > to outline that the selinux module only appears if selinux was enabled at > boot time, else it's hidden? Hi Robert, yes, no problem with that.