Cockpit crashes trying to open /var/log/lastlog

English Applications
1

Back again trying to get cockpit working on a vanilla microos install (Other thread: MicroOS cockpit install broken dependencies)

After getting cockpit-ws running, I create a user account and try to log in from the web console. Cockpit seems to crash; the login page prints “Internal error in login process”, and cockpit-session hits an exception:

journalctl:
May 07 23:00:26 vbox cockpit-session[1817]: cockpit-session: failed to open /var/log/lastlog: No such file or directory
May 07 23:00:26 vbox cockpit-session[1841]: Traceback (most recent call last):
...
May 07 23:00:26 vbox cockpit-session[1841]: PermissionError: [Errno 1] Operation not permitted

cockpit is trying to open lastlog, but lastlog isn’t installed by default on microos. Instead we have lastlog2 and aulastlog which use different files completely.

Anyone understand how this is supposed to work? If someone has journalctl output for a successful login on microos for comparison I’d be curious to see what the intended behavior is.

2

Actually this seems to be another selinux issue. If I make the user logging in unconfined, I still get the lastlog error, but it’s nonfatal. The following python PermissionError I guess is unrelated. Checking /var/log/audit/audit.log, I don’t see any obvious clues

3

Read Portal:SELinux - openSUSE Wiki (search for “Report a SELinux bug”) what information is needed to troubleshoot SELinux.

4

A few days ago I had SELinux issues with cockpit in Leap 16-beta. In this case it was solved by forcing re-installing of package cockpit-selinux-policies and reboot,

sudo zypper install -f cockpit-selinux-policies

5

I’ll follow the steps and provide the info here

6

A few days ago I had SELinux issues with cockpit in Leap 16-beta. In this case it was solved by forcing re-installing of package cockpit-selinux-policies and reboot,

I don’t think this is the issue, because this is on microos which comes with selinux installed and enabled at first boot. From reading the attached thread it sounds specific to situations on TW or leap where selinux is installed after cockpit.

7

Filed a bug here: 1243023 – [SELinux] Cockpit permission denied with staff_u users

8

Which documentation claims that this was expected to work? Does it work for a normal user not explicitly mapped to a SELinux user?

And your bug report does not provide the most vital part of information - SELinux denials.

9

There is no opensuse documentation on what users are supported (in the section 8 pages on cockpit and selinux at least)

selinux denials are in the attachment

10

I cannot reproduce it in the Tumbleweed. Without cockpit SELinux policy module the cockpit services do not even start. With policy module and SELinux staff_u user the login fails early with “Internal error in login process” and without any non-hidden AVC. Enabling donotaudit rules is not really helpful as there are too many of them, but I suspect the default staff_u login context does not have access to the cockpit sockets at the very least.

In any case - I do not see anything that warrants bug report. openSUSE is using targeted policy that confines services. Nothing is prepared for additional user confinement. If you have convincing arguments why it is required, you need to discuss it with developers upstream as cockpit SELinux policy comes as part of the cockpit project.

11

This is good to know, I assumed it was from opensuse. In this case the documentation really should be upstream, I’ll inquire there