Failed SDDM Login to KDE Plasma for a Specific User

[Bob Jackson]

Have a Fedora 26 laptop which I update on a weekly basis by sudo from my regular account. 
After applying a batch of updates, including a new kernel, I rebooted.  At the login
screen I entered my standard login credentials but Plasma did not launch and it dropped
back to the login screen.

I tried an alternate account.  It worked.

Switched to VT2 and logged in with standard credentials.  While doing so, the terminal
reported, "Failed to connect to X server".

From that terminal ran:

startx /usr/bin/startkde

which brought up my standard KDE environment.  I worked this way for a couple of days
trying to find clues in logs and discussion groups.  Did find a recent thread on
fedoraforum.org that described my situation exactly, but had no solution.

https://forums.fedoraforum.org/showthread.php?p=1794119

Finally, while my workaround session was open, I went back to VT1 and tried another login
from SDDM.  It failed, but back in my working session I had an SELinux alert, which told
me:

SELinux is preventing sddm-helper from write access on the file .Xauthority.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that sddm-helper should be allowed write access on the .Xauthority file by
default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'sddm-helper' --raw | audit2allow -M my-sddmhelper
# semodule -X 300 -i my-sddmhelper.pp

I applied the recommended fixes and tried again.  Failed but received another alert:

SELinux is preventing sddm-helper from open access on the file /home/xxxx/.Xauthority.

*****  Plugin restorecon (99.5 confidence) suggests   ************************

If you want to fix the label. 
/home/xxxx/.Xauthority default label should be xauth_home_t.
Then you can run restorecon. The access attempt may have been stopped due to insufficient
permissions to access a parent directory in which case try to change the following command
accordingly.
Do
# /sbin/restorecon -v /home/xxxx/.Xauthority

Applied this fix and tried again ... with success.

With the benefit of hindsight, does anyone have thoughts on why this might have happened,
what these SELinux fixes (particularly the first two) did and whether this is a permanent
resolution?

   Thanks,
      -- Bob

[Pete Travis]

On Sep 20, 2017 10:57 AM, "Bob Jackson" <bobj204(a)gmail.com&gt; wrote:

Have a Fedora 26 laptop which I update on a weekly basis by sudo from my
regular account.  After applying a batch of updates, including a new
kernel, I rebooted.  At the login screen I entered my standard login
credentials but Plasma did not launch and it dropped back to the login
screen.

I tried an alternate account.  It worked.

Switched to VT2 and logged in with standard credentials.  While doing so,
the terminal reported, "Failed to connect to X server".

From that terminal ran:

startx /usr/bin/startkde

which brought up my standard KDE environment.  I worked this way for a
couple of days trying to find clues in logs and discussion groups.  Did
find a recent thread on fedoraforum.org that described my situation
exactly, but had no solution.

https://forums.fedoraforum.org/showthread.php?p=1794119

Finally, while my workaround session was open, I went back to VT1 and tried
another login from SDDM.  It failed, but back in my working session I had
an SELinux alert, which told me:

SELinux is preventing sddm-helper from write access on the file .Xauthority.

*****  Plugin catchall (100. confidence) suggests
 **************************

If you believe that sddm-helper should be allowed write access on the
.Xauthority file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'sddm-helper' --raw | audit2allow -M my-sddmhelper
# semodule -X 300 -i my-sddmhelper.pp

I applied the recommended fixes and tried again.  Failed but received
another alert:

SELinux is preventing sddm-helper from open access on the file
/home/xxxx/.Xauthority.

*****  Plugin restorecon (99.5 confidence) suggests
 ************************

If you want to fix the label.
/home/xxxx/.Xauthority default label should be xauth_home_t.
Then you can run restorecon. The access attempt may have been stopped due
to insufficient permissions to access a parent directory in which case try
to change the following command accordingly.
Do
# /sbin/restorecon -v /home/xxxx/.Xauthority

Applied this fix and tried again ... with success.

With the benefit of hindsight, does anyone have thoughts on why this might
have happened, what these SELinux fixes (particularly the first two) did
and whether this is a permanent resolution?

   Thanks,
      -- Bob
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org


When in doubt, you should always try restoring default file contexts before
applying custom policy.  You can use 'restorecon' to this in a targeted
manner, but I would recommend 'fixfiles onboot;reboot' which will relabel
the whole filesystem tree during early boot, before any mislabeling causes
problems.

-- Pete

[Bill Shirley]

The trouble with the instructions:

# ausearch -c 'sddm-helper' --raw | audit2allow -M my-sddmhelper # semodule -X 300
-i my-sddmhelper.pp

is the 1st time it can fail on file 'open'.  When you do the above and
'open' is allowed but then get shot down when your program tries
to 'write', 'relabelfrom', 'setattr', 'relabelto', or
'create'.   Do this first:
setenforce 0
Do the activity that triggers the AVC, then:
setenforce 1

# ausearch -c 'sddm-helper' --raw | audit2allow -M my-sddmhelper # semodule -X 300
-i my-sddmhelper.pp

This will allow all the activities that the program needs.

Bill

On 9/20/2017 11:56 AM, Bob Jackson wrote:
>  Have a Fedora 26 laptop which I update on a weekly basis by sudo from
> my regular account.  After applying a batch of updates, including a new kernel, I
> rebooted.  At the login screen I entered my standard login credentials but Plasma did not
> launch and it dropped back to the login screen.
>
>  I tried an alternate account.  It worked.
>
>  Switched to VT2 and logged in with standard credentials.  While doing so, the terminal
> reported, "Failed to connect to X server".
>
>   From that terminal ran:
>
>  startx /usr/bin/startkde
>
>  which brought up my standard KDE environment.  I worked this way for a couple of days
> trying to find clues in logs and discussion groups.  Did find a recent thread on
> fedoraforum.org that described my situation exactly, but had no solution.
>
>  https://forums.fedoraforum.org/showthread.php?p=1794119
>
>  Finally, while my workaround session was open, I went back to VT1 and tried another login
> from SDDM.  It failed, but back in my working session I had an SELinux alert, which told
> me:
>
>  SELinux is preventing sddm-helper from write access on the file .Xauthority.
>
>  *****  Plugin catchall (100. confidence) suggests   **************************
>
>  If you believe that sddm-helper should be allowed write access on the .Xauthority file by
> default.
>  Then you should report this as a bug.
>  You can generate a local policy module to allow this access.
>  Do
>  allow this access for now by executing:
>  # ausearch -c 'sddm-helper' --raw | audit2allow -M my-sddmhelper
>  # semodule -X 300 -i my-sddmhelper.pp
>
>  I applied the recommended fixes and tried again.  Failed but received another alert:
>
>  SELinux is preventing sddm-helper from open access on the file /home/xxxx/.Xauthority.
>
>  *****  Plugin restorecon (99.5 confidence) suggests   ************************
>
>  If you want to fix the label.
>  /home/xxxx/.Xauthority default label should be xauth_home_t.
>  Then you can run restorecon. The access attempt may have been stopped due to insufficient
> permissions to access a parent directory in which case try to change the following command
> accordingly.
>  Do
>  # /sbin/restorecon -v /home/xxxx/.Xauthority
>
>  Applied this fix and tried again ... with success.
>
>  With the benefit of hindsight, does anyone have thoughts on why this might have happened,
> what these SELinux fixes (particularly the first two) did and whether this is a permanent
> resolution?
>
>      Thanks,
>         -- Bob
>  _______________________________________________
>  users mailing list -- users(a)lists.fedoraproject.org
>  To unsubscribe send an email to users-leave(a)lists.fedoraproject.org

[Bob Jackson]

The pointer by Pete toward a more global approach was helpful and led me to run a
'fixfiles check'.  This revealed lots of contexts needing restoration,
particularly in my home directory.  Seems to suggest that running fixfiles is a good
preventive measure to perform regularly.

It was also suggested to me offline that having restored the proper context for
.Xauthority, it was no longer necessary to have a particular local policy in effect for
my-sddmhelper.  So it could be deleted with 'semodule -r my-sddmhelper'.

The origin of the problem seemed to arise from running package updates, but exactly how
will remain a mystery.

Learned more about the tools and thought processes for understanding SELinux problems. 
Thanks all.

  -- Bob