Normal user losing all rights on /tmp-dirs
 

Hi guys, I've recently stumbled over some strange behaviour of kde on slackware. When working as normal user starting apps under kde suddenly quits with something like "kde-init couldn't start %app-name%". It turned out that the cause was the user losing all rights on his directories in /tmp. Also regiving all rights as before doesn't change anything.
Please help me, this is really annoying, because you have to restart kde afterwards to actually go on working.
I don't know if it's a problem of Slackware or of KDE or some other app, but I no it's not limited to Slackware 10.2. It occured also on older versions.
Any ideas?

I only encountered this problem with a bad written slackbuild script that set all permissions in /tmp to root:root. No idea though why you have this problem.

Switch to runlevel 1 and you should be safe to delete all that has been created automatically in /tmp. Then do a "chmod 1777 -R /tmp" to set the right permissions.

This might happen if you for instance installed a third-party Slackware package that messed up the directory permissions.

Look at the premissions for the /tmp directory, that directory should be writable by everyone:
If that is not the case, run to fix it.

Eric

I would think that if /tmp permissions where wrong (ie read-only) on a permanent basis, he would not even be able to start KDE or the problem would exist from the start. In that case restarting would not fix it.

I think I can reproduce the error he is experiencing by opening a root terminal and deleting the ./X11-unix directory while still in KDE as the nomal user. Attempting to start apps gives me the same error message. But the rest of the desktop eventually grinds to halt as well.

I can also reproduce it to a degree if I delete the xauth.XXXXxxxx file created in /tmp when I open a konqueror session with kdesu (root konqueror window). I can no longer open editors by clicking the file icon in this root window getting the same kde-init error.

This makes me wonder if something is cleaning out his /tmp file while he is using it and he is loosing his lock on X. A cron job maybe?

Just a guess.

Chmod is actually not the right solution, because as you said, permissions of /tmp are ok on boot. They change some time later!
But I have to clear up some things. Of course going back to kdm does actually not fix it. I have to restart X to work on.
That would fit with your theses. But neither the .X11-unix directory nor the xauth.XXXXxxxx file get deleted.
And if Slackware does not ship with pre-configured cron jobs, they are also not the cause. I haven't configured one on my own.

KDE is not freezing, I can work on with the apps opened, but accessing a function not yet started quits with an error message (Means not only starting apps, but also copying files in krusader for example)

Losing Rights in /tmp is just limited to my user-dirs, not to the others. I think ./X11-unix keeps its permissions.

Maybe interesting that not all apps quit with an error. Midnight Commander starts with an error message, saying mc's tmp-directory is not owned by user, but is working normal afterwards.

Slackbuild-scripts can be a cause, as I'm working a lot with them. But I'm working with a slightly modified version of linuxpackages.net's slackbuilds package. The relevant part might be:
But that is only working in /tmp/%app-source%, not in /tmp itself, nor in /.

Probably this can help a bit.

If a script modifies the permissions restarting the X server should not cure anything, so after restarting you should have the same hazzle IMHO.
About the /tmp/%app-source% thing: an error might occur if you refer to an app-source name that is in some kind not regular, for example if a source folder is named with capital letters or without version number but you didn't adjust the slackbuild script. To prevent from such unwanted chmods I switched from a twoliner to an oneliner (cd $SRCDIR && chmod -R root.root .) so the permissions are changed only if the source folder has been entered without any error.

But as said before, if a plain X restart corrects the permissions, this is probably not your problem's solution :(

I have now some clearance about what is happening.
This is my /tmp-folder at normal:

And this is it just some minutes later, where I lose the rights

And after restarting X it looks like this

Now fact is I was compiling openexr at the time happening, making me think of the Slackbuilds again, but executing the same script after restart again, did exactly nothing but what it should.
What I see is, that "session_mm_apache0.sem" and "xauth.XXXXSllGxc" got read access. And ".X0-lock" got write access.
Now after restart the apache-file stays the same, and apache is working fine. Which makes me think of the .X0-lock being the cause for my problems.
But the next question would then be, what would cause this files to change permissions? As I said, the only thing I was doing was compiling.

What are these:

drwxr-xr-x 22 root root 1060 2006-08-28 15:56 openexr-1.4.0/
drwxr-xr-x 2 root root 40 2006-08-28 15:56 package-openexr/

These are not present in case 1 but are in case 2 and gone again in case 3.
They are owned by root.

As I described above, I was compiling openexr when it was happening.
The first one are the sources, the second one is the package-directory.
I use to delete these directories when the package is ready.
I build it using a Slackbuild-script, which was executed as root.

However, I don't think that this has something to do with it, as I did everything again afterwards, with no effects on /tmp.