abrt bug #1665740

*** This bug has been marked as a duplicate of bug 1665740 ***

I am still getting the gibberish directory created in $HOME on login with SDDM. It does not create the directory if using KDM. I am using abrt-2.11.1-3.fc29.x86_64 and I even tried removing abrt and still get the problem.

Steps to reproduce:

dnf group install "KDE Plasma Workspaces"
systemctl set-default graphical.target
systemctl enable sddm

Login with SDDM and a gibberish directory will be created in $HOME.

(In reply to brh from comment #2)
> I am still getting the gibberish directory created in $HOME on login with
> SDDM. It does not create the directory if using KDM. I am using
> abrt-2.11.1-3.fc29.x86_64 and I even tried removing abrt and still get the
> problem.
> 
> Steps to reproduce:
> 
> dnf group install "KDE Plasma Workspaces"
> systemctl set-default graphical.target
> systemctl enable sddm
> 
> Login with SDDM and a gibberish directory will be created in $HOME.

I am unable to reproduce the issue with either a GNOME or KDE session, regardless of the display manager.

I have this problem on two different computers that had their install copied over from the same VMware virtual drive. The install was done on January 15, 2019 and a dnf upgrade has been done again today and the problem still persists on these two machines. Today I again installed Fedora 29 Workstation on a VMware virtual machine and the problem does not exist in this new install, but dnf upgrade on my other installs is not fixing the problem. Here are the steps I initially did on January 15 and again today.

1) Download https://download.fedoraproject.org/pub/fedora/linux/releases/29/Workstation/x86_64/iso/Fedora-Workstation-netinst-x86_64-29-1.2.iso
2) Install Fedora 29 on VMware Workstation 15 Player virtual machine accepting all defaults except chose "Store virtual disk as a single file" and set OS to Fedora 64bit
3) Accept all defaults for Fedora install except:
   A. Chose custom storage and created a single standard ext4 partition with mount point / size 18 GB
   B. Software Selection: KDE Plasma Workspaces
4) After installation is complete, login as normal user with SDDM and a gibberish directory in $HOME is created

So it appears the problem has been fixed if downloading a new ISO install image, but dnf upgrade on my existing installs doesn't fix the problem.

I got the new install to make the gibberish directory in $HOME by disabling SELinux

vi /etc/selinux/config
SELINUX=disabled

Give that a try and see if you can reproduce the problem.

(In reply to brh from comment #5)
> I got the new install to make the gibberish directory in $HOME by disabling
> SELinux
> 
> vi /etc/selinux/config
> SELINUX=disabled
> 
> Give that a try and see if you can reproduce the problem.

Still nothing.

Do you remove the directories yourself? If so, how? As far as I can see, Dolphin chokes promptly on those.
Did you perform a full upgrade? The binary that used to create the directories was abrt-applet, which lives in the abrt-gui package.

I am removing the directories with rm -r ''$'\020''���cU'. I did 'dnf upgrade' which should upgrade everything correct? I have removed abrt-gui with 'dnf remove abrt-gui' and I still get the gibberish direcotry, so it seems this problem is not related to abrt. Have you done a clean install onto a VMware virtual machine like I outlined above? Maybe it has something to do with VMware. The SELinux setting in /etc/selinux/config makes a difference. If set to either SELINUX=disabled or SELINUX=permissive the gibberish directory is created. Make sure you reboot after changing that setting.

Reassigning back to sddm.

Can you post the contents of your /etc/sddm.conf?  In particular, any non-commented lines you've customized.

#/etc/sddm.conf
[Autologin]
Relogin=false
Session=
User=

[General]
HaltCommand=
RebootCommand=

[Theme]
Current=01-breeze-fedora
CursorTheme=Adwaita

[Users]
MaximumUid=60000
MinimumUid=1000

This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.