Can't login via KDM after upgrading to Precise

[dibl]

:eek:

Those are all root-owed files?

:eek:

All that KDE-Look content, including the installation scripts?

:eek:

I don't know where you were informed that it's OK to have root-owned files and directories anywhere under your ~/Montblanc directory, but I think we just found the problem.

Do you know how to use "sudo chown" or else Alt-F2 "kdesudo dolphin" to change all that stuff back to Montblanc (or whatever your user name is)?

[Montblanc]

:eek:

Those are all root-owed files?

:eek:

All that KDE-Look content, including the installation scripts?

:eek:

I don't know where you were informed that it's OK to have root-owned files and directories anywhere under your ~/Montblanc directory, but I think we just found the problem.

Do you know how to use "sudo chown" or else Alt-F2 "kdesudo dolphin" to change all that stuff back to Montblanc (or whatever your user name is)?

Uhm, could you please explain why non-vital files in my home directory should not be ok? There's no file that needs to be owned by me in that output, but most of all, none of those files can in any way make my system think my password is incorrect. I can chown in any moment, but I could delete those files in any moment as well. For example, the sysctl backup is from Dapper (2006). They're just checkinstall results and backups of files owned by root and they're all under control. The only files that could possibly be owned by me are these ones:

./.xinput.d
./.nano_history
./.kde/share/apps/RecentDocuments/Caledonia_1920x1200.png.desktop
./.kde/share/applnk/AdobeAIR-application-vnd.adobe.air-application-installer-package+zip.desktop
./.aptitude/config
./.aptitude/cache
./.ure
./.ure/javasettings_Linux_x86.xml

But there's a reason why they're owned by root and I know for sure that they're not related to my problem.

Thank you so much for helping me out, but I'm getting nervous. I shouldn't have upgraded by changing every "oneiric" occurrence to "precise" in my sources.list but my system was not triggering a distribution upgrade. Something has happened while upgrading that way, but I don't know what.

[dibl]

There is nothing wrong with backing up any and all system files that you wish, in your user's home folder. HOWEVER, please note what happens to the ownership when the user makes the backup:

don@imerabox:~$ ls -la /etc/sysctl.conf
-rw-r--r-- 1 root root 2246 Nov  3  2011 /etc/sysctl.conf
don@imerabox:~$ cp /etc/sysctl.conf .
don@imerabox:~$ ls -la sysctl.conf
-rw-r--r-- 1 don don 2246 May  4 15:45 sysctl.conf

Any file copied by the user into his home directory becomes his file. What you have apparently done is used "sudo" or a root-mode file manager and copied system files into your user's folder -- that is a no-no. Moreover, you have somehow managed to create configuration files of such tools as aptitude in the user's home folder, with root ownership. For example, to run a KDE user session, everything under ~/.kde has to be owned by the user:

don@imerabox:~$ ls -la .kde
total 32
drwxr-xr-x  6 don don  4096 Nov 21 13:08 .
drwx------ 54 don don 12288 May  4 15:45 ..
drwxr-xr-x  2 don don  4096 Apr 28 15:14 Autostart
lrwxrwxrwx  1 don don    21 Nov 15 09:04 cache-imerabox -> /var/tmp/kdecache-don
drwxr-xr-x  2 don don  4096 Nov 21 13:08 env
drwxr-xr-x  6 don don  4096 Nov 21 13:08 share
drwxr-xr-x  2 don don  4096 Nov 21 13:08 shutdown
lrwxrwxrwx  1 don don    16 Nov 15 09:04 socket-imerabox -> /tmp/ksocket-don
lrwxrwxrwx  1 don don    12 Nov 15 09:04 tmp-imerabox -> /tmp/kde-don

I'm not willing to spend any more time debating it -- we have found the cause of your broken KDE login.

[Montblanc]

My .kde folder and X files/folders have the right owners and permissions, while the files from my output are consciously owned by root, there is no problem with that. If it was just a matter of permissions, I wouldn't have been able to login with startx, the logs would have reported that and I wouldn't have had to open a thread. You're clearly not understanding what I'm talking about but I do sincerely appreciate your help, though.

By the way, I made some progress! There was nothing wrong with the uids, the LOGIN (pam) session is always started by uid=0 for every user as a normal behaviour.

I tried adding my user to the "nopasswdlogin" group and:

1) lightdm works as it should, it asks for the password, recognizes it and logs me in (although I see the X cursor on a black screen for a moment before starting ksplash)
2) kdm logs me automatically in.

Clearly I don't have any authentication failures at this point and I can finally mount partitions, update files through apper and so on... but I want to use kdm by entering a password. Also, I don't like lightdm. If my user is not in the "nopasswdlogin" group, kdm and lightdm don't recognize my password, but when it is, kdm skips the greeter screen (no matter which kdmrc settings I use), while lightdm contradicts the "no password login" but it works as I wanted.

I can tell now that it's probably a pam issue (or a consolekit/dbus one), it's just something that's preventing my input to be recognized as a password for my user. /etc/passwd and pam files are just fine, though. I'm getting somewhere, but maybe I should dig further...

Can you tell me something about this nopasswdlogin experience and how I could possibly have my dear kdm back to normal?

Thank you so much!

[dibl]

You are correct that PAM authorization is related to your problem, but there is more to know, related to X server security. I'm not an expert on it (if you never run "sudo kdepkg", and you never allow root-owned files in your user folder, then you never need to become an expert on this subject). Here are the terms that will lead you and Google to the relevant information:

xsecurity
mit-magic-cookie-1
xdm-authorization-1
.Xauthority

Good luck with the research!

[Snowhog]

With very few exceptions, NOTHING in a users /home directory should be owned by root. Period. dibl is correct, that your problem is almost certainly the result of root having mucked up your users /home directory. I suspect specifically, your ./.xinput.d directory/contents.

I would do as dibl suggested, and change everything in your user /home directory to your user name ownership. Open a console and verify that you are in your users home directory. If you aren't, cd into it. Once in your user home directory, type:

sudo chown -R username:username

where username is your username you log in with. This will change the ownership:group of every directory and file within your user /home directory to you, which is what everything in there should be.

[Montblanc]

With very few exceptions, NOTHING in a users /home directory should be owned by root. Period. dibl is correct, that your problem is almost certainly the result of root having mucked up your users /home directory. I suspect specifically, your ./.xinput.d directory/contents.

I'm very sorry but I have to contradict you. I don't see anything wrong in consciounsly executing a "sudo checkinstall" or keeping root permissions to some files to prevent deleting them accidentally. Files needed to login are okay. I can have anything I want owned by root in my home if I want to, unless those files *need* to be owned by me. None of those files *needs* to be owned by me (especially the .xinput.d folder, which is empty) but for your happiness, I chowned anything in my home and nothing has changed. So this is not a matter of owners of folders and files in my home, period. And let me add that X authorization files are fine. I experienced Xauthority issues in the past, but they were easy to solve. I've never seen a problem like this, that's why I'm going mad like a dog. I'm not a pam expert, all I can see in the logs are errors without a reason.

What I'm getting now, since I found out the nopasswdlogin workaround, is a similar problem, but with no solution.

I know you're trying to help me and I thank you for this, but I should probably stick with with lightdm+nopasswdlogin and just give up...

[Snowhog]

Montblanc@

I will moderate my last statement as to files in a users /home directory shouldn't be owned by root. If you specifically put root owned files into your /home directory, then yes, no issues. Under some conditions, root can muck up a users /home directory, and that can/does create problems.

[Montblanc]

Montblanc@

I will moderate my last statement as to files in a users /home directory shouldn't be owned by root. If you specifically put root owned files into your /home directory, then yes, no issues. Under some conditions, root can muck up a users /home directory, and that can/does create problems.

Of course, thanks for the reminder! By the way, it seems I really found something. My password contains a special character, that would also explain why this bug (is it?) was not reproducible by someone else. I'm changing my password right now. Update asap.

P.S.: Do you have these lines in your xorg.conf?

Section "Files"
    FontPath        "unix/:7100"
EndSection

[Snowhog]

I don't have an xorg.conf file -- my GPU is an integrated Intel, so I don't use/need/require the file.