Can you log into your system in text mode (or ssh) to get the AVCs from the log *after* you've tried and failed to log into KDE via gdm? Otherwise we don't have much to go on.

1. Try to log into KDE via gdm
2. Fail
3. Login to a tty or ssh
4. sudo ausearch -m AVC -ts boot
5. Post output here

I just did as instructed.  More precisely, I first ran

ausearch -ts boot -sv no

followed by

ausearch -m AVC -ts boot

Here's what I got:

time->Tue Oct 10 13:15:40 2023
type=CRED_ACQ msg=audit(1696958140.947:2000): pid=30674 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='op=PAM:setcred grantors=? acct="gdm" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
----
time->Tue Oct 10 13:16:20 2023
type=CRED_ACQ msg=audit(1696958180.214:2034): pid=31204 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='op=PAM:setcred grantors=? acct="donovan" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
----
time->Tue Oct 10 13:16:20 2023
type=AVC msg=audit(1696958180.630:2040): avc:  denied  { read } for  pid=31161 comm="gdm-session-wor" name="motd" dev="tmpfs" ino=11433 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cockpit_var_run_t:s0 tclass=lnk_file permissive=0
----
time->Tue Oct 10 13:16:22 2023
type=USER_END msg=audit(1696958182.864:2047): pid=31161 uid=0 auid=1000 ses=32 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_close grantors=? acct="donovan" exe="/usr/libexec/gdm/gdm-session-worker" hostname=hbrew-tw addr=? terminal=/dev/tty3 res=failed'
----
time->Tue Oct 10 13:16:20 2023
type=AVC msg=audit(1696958180.630:2040): avc:  denied  { read } for  pid=31161 comm="gdm-session-wor" name="motd" dev="tmpfs" ino=11433 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cockpit_var_run_t:s0 tclass=lnk_file permissive=0

The first four entries are for '-sv no'.  The final entry is for '-m AVC'.

I hope this helps.

It might be worth mentioning that I've tried the same thing on Fedora, and it works without problem there.  It would be nice if this were fixed, but I'm currently using GNOME on Tumbleweed, and it works very well for me.

Thanks for your help.

I tried to reproduce the issue in different ways but I can not reproduce it.

What i tried (first try):
- Install tumbleweed with gnome + update to latest version + install selinux packages & set to enforcing etc
- sudo zypper in patterns-kde-kde
- Log out from gnome
- In gdm select "Plasma (X11)" or "Plasma (Wayland)"
- It starts kde normally, no issues

What i also tried (second try):
- Install tw with KDE + update to latest version + install selinux packages & set to enforcing etc
- Install gdm    
- Change default display manager to gdm:    
sudo update-alternatives --set default-displaymanager /usr/lib/X11/displaymanagers/gdm    
- Log out, check if it is gdm, login to kde, still okay

What are you doing differently? Are you doing things with cockpit? If so what exactly?
Can you log into gnome via gdm successfully?

Also could you send me the selinux policy version, gdm version and kde version? (and if used also the cockpit version)

Thanks a lot :)

Thank you for you investigation and helpful comments.

The problem appears to be on my end.  Before I explain why I'm sure about this, I'll answer some of your questions.

I haven't used cockpit for anything.  I can log into gnome with gdm without problem, and I can log into plasma (wayland or x11) with sddm.  The problem arises only when trying to log into plasma from gdm.  I'm using the 'targeted' policy of selinux; I think this is the default.

I'm using Tumbleweed, which I update every day, so I'm using the current versions of gnome and kde.

Also, I'll add that I ran 'restorecon -r /home/donovan' (my home directory), and it did not help.  I have tested on two different machines, both running Tumbleweed, and they both have the problem.  The plasma setup is similar on both machines.

However, there is something wrong with my configuration.  To test this, I used Yast to create a new user.  I then logged out, and tried to log into plasma wayland as this new user, using gdm.  There was no problem.  I did not test it extensively, so it might break with further use, but there's no reason to think so.

I'll try to fix this later.  I may just delete my plasma configuration files, log in, and then recreate them as best I can.

In any case, you'll probably want to close this bug.

Ah okay, before nuking your config files, maybe try restorecon on the whole system, not just your user:

-> dry run
sudo restorecon -Rvn / 
-> see if there is any output and if so and it makes sense, run 
sudo restorecon -Rv <the folder that makes sense or just whole / > 

If you find out what caused it, please let us know, then we have it in case someone else also runs into it.

Thanks, and feel free to comment again in case of any questions. Closing the bug

I got it to work on my machine, but I'm confused about what was broken.

One reason I had a problem is that the audit log did not include the reported avc problem.  I found it in the system journal, though.  The relevant line I found was:

Oct 16 16:57:25 hbrew-tw systemd[8529]: selinux: avc:  denied  { start } for auid=1000 uid=1000 gid=1000 path="/usr/lib/systemd/user/plasma-ksplash.service" cmdline="/usr/bin/startplasma-wayland" function="bus_unit_method_start_generic" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_unit_file_t:s0 tclass=service permissive=0

As I indicated before, I don't know selinux very well.  I understood this to mean that an executable labeled as system_u:system_r:xdm_t:s0 is not permitted to start a service file labeled as system_u:object_r:systemd_unit_file_t:s0.  I searched the Web for help, and skipping details, I thought the following commands might work:

echo 'Oct 16 16:57:25 hbrew-tw systemd[8529]: selinux: avc:  denied  { start } for auid=1000 uid=1000 gid=1000 path="/usr/lib/systemd/user/plasma-ksplash.service" cmdline="/usr/bin/startplasma-wayland" function="bus_unit_method_start_generic" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_unit_file_t:s0 tclass=service permissive=0' | audit2allow -M fix
semodule -i fix.pp

I tried it, and it did work.

I understand the fix, as far as it goes.  It granted the needed permission, and I'm now able to log into plasma from gdm.  I don't know whether the fix will survive a reboot, but I'll find out the next time I reboot.

There are several things I don't understand, though.  For example, why was I able to log in when I created a new user?  And why were you able to log in?  I suspect this rule, or something similar, should be added to your selinux configuration, but even if you do so, it may fix a problem that shows up only in certain circumstances.