LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 08-27-2006, 07:09 AM   #1
ppr:kut
Member
 
Registered: Aug 2006
Location: Netherlands
Distribution: Slackware
Posts: 361

Rep: Reputation: 93
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?
 
Old 08-27-2006, 09:26 AM   #2
titopoquito
Senior Member
 
Registered: Jul 2004
Location: Ruhr Area, Germany
Distribution: Slackware64 14.0
Posts: 1,517

Rep: Reputation: 90
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.
 
Old 08-27-2006, 09:28 AM   #3
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,268

Rep: Reputation: Disabled
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:
Code:
drwxrwxrwt  27 root root   4096 2006-08-27 16:28 tmp/
If that is not the case, run
Code:
chmod 1777 /tmp
to fix it.

Eric
 
Old 08-27-2006, 11:04 AM   #4
Franklin
Senior Member
 
Registered: Oct 2002
Distribution: Slackware, WinXP, Windows 7
Posts: 1,253

Rep: Reputation: 55
Quote:
Originally Posted by Alien Bob
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:
Code:
drwxrwxrwt  27 root root   4096 2006-08-27 16:28 tmp/
If that is not the case, run
Code:
chmod 1777 /tmp
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.
 
Old 08-28-2006, 05:30 AM   #5
ppr:kut
Member
 
Registered: Aug 2006
Location: Netherlands
Distribution: Slackware
Posts: 361

Original Poster
Rep: Reputation: 93
Quote:
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?
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:
Quote:
fix_source() {
chown -R root.root .
find . -perm 664 -exec chmod 644 {} \;
find . -perm 600 -exec chmod 644 {} \;
find . -perm 444 -exec chmod 644 {} \;
find . -perm 400 -exec chmod 644 {} \;
find . -perm 440 -exec chmod 644 {} \;
find . -perm 777 -exec chmod 755 {} \;
find . -perm 775 -exec chmod 755 {} \;
find . -perm 511 -exec chmod 755 {} \;
find . -perm 711 -exec chmod 755 {} \;
find . -perm 555 -exec chmod 755 {} \;
find . -perm 666 -exec chmod 644 {} \;
#find . -perm 2775 -exec chmod 755 {} \;
#find . -perm 2755 -exec chmod 755 {} \;
}
But that is only working in /tmp/%app-source%, not in /tmp itself, nor in /.

Probably this can help a bit.
 
Old 08-28-2006, 10:54 AM   #6
titopoquito
Senior Member
 
Registered: Jul 2004
Location: Ruhr Area, Germany
Distribution: Slackware64 14.0
Posts: 1,517

Rep: Reputation: 90
Quote:
Originally Posted by ppr:kut
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 /.
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
 
Old 08-28-2006, 11:54 AM   #7
ppr:kut
Member
 
Registered: Aug 2006
Location: Netherlands
Distribution: Slackware
Posts: 361

Original Poster
Rep: Reputation: 93
I have now some clearance about what is happening.
This is my /tmp-folder at normal:

Quote:
drwxrwxrwt 8 root root 220 2006-08-28 15:41 ./
drwxr-xr-x 18 root root 408 2006-08-28 15:41 ../
drwxrwxrwt 2 root root 100 2006-08-28 14:40 .ICE-unix/
drwx------ 2 hwiesinger root 160 2006-08-28 15:38 kde-hwiesingerlXuDTL/
drwx------ 2 root root 60 2006-08-28 14:40 kde-root/
drwx------ 3 hwiesinger root 320 2006-08-28 15:38 ksocket-hwiesinger/
drwx------ 3 root root 280 2006-08-28 14:41 ksocket-root/
-rw------- 1 root root 0 2006-08-28 11:50 session_mm_apache0.sem
-r--r--r-- 1 root root 11 2006-08-28 11:51 .X0-lock
drwxrwxrwt 2 root root 60 2006-08-28 11:51 .X11-unix/
-rw------- 1 root root 53 2006-08-28 14:40 xauth.XXXXSllGxc
And this is it just some minutes later, where I lose the rights

Quote:
drwxrwxrwt 10 root root 260 2006-08-28 15:57 ./
drwxr-xr-x 18 root root 408 2006-08-28 15:46 ../
drwxrwxrwt 2 root root 100 2006-08-28 14:40 .ICE-unix/
drwx------ 2 root root 160 2006-08-28 15:47 kde-hwiesingerlXuDTL/
drwx------ 2 root root 60 2006-08-28 14:40 kde-root/
drwx------ 3 root root 320 2006-08-28 15:47 ksocket-hwiesinger/
drwx------ 3 root root 280 2006-08-28 14:41 ksocket-root/
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/
-rw-r--r-- 1 root root 0 2006-08-28 11:50 session_mm_apache0.sem
-rw-r--r-- 1 root root 11 2006-08-28 11:51 .X0-lock
drwxrwxrwt 2 root root 60 2006-08-28 11:51 .X11-unix/
-rw-r--r-- 1 root root 53 2006-08-28 14:40 xauth.XXXXSllGxc
And after restarting X it looks like this

Quote:
drwxrwxrwt 10 root root 300 2006-08-28 16:03 ./
drwxr-xr-x 18 root root 408 2006-08-28 15:46 ../
srw-rw---- 1 hwiesinger audio 0 2006-08-28 16:03 alsa-dmix-10839-1156773785-693494=
srw-rw---- 1 hwiesinger audio 0 2006-08-28 16:03 alsa-dmix-10839-1156773785-699389=
drwxrwxrwt 2 root root 140 2006-08-28 16:03 .ICE-unix/
drwx------ 2 hwiesinger root 120 2006-08-28 16:03 kde-hwiesingeregCrr5/
drwx------ 2 root root 160 2006-08-28 15:47 kde-hwiesingerlXuDTL/
drwx------ 2 root root 60 2006-08-28 16:03 kde-root/
drwx------ 3 root root 320 2006-08-28 15:47 ksocket-hwiesinger/
drwx------ 3 hwiesinger root 320 2006-08-28 16:03 ksocket-hwiesinger1ZBvs5/
drwx------ 3 root root 280 2006-08-28 16:03 ksocket-root/
-rw-r--r-- 1 root root 0 2006-08-28 11:50 session_mm_apache0.sem
-r--r--r-- 1 root root 11 2006-08-28 16:02 .X0-lock
drwxrwxrwt 2 root root 60 2006-08-28 16:02 .X11-unix/
-rw------- 1 root root 53 2006-08-28 16:03 xauth.XXXXXhDfla
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.
 
Old 08-28-2006, 12:55 PM   #8
Franklin
Senior Member
 
Registered: Oct 2002
Distribution: Slackware, WinXP, Windows 7
Posts: 1,253

Rep: Reputation: 55
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.
 
Old 08-29-2006, 07:24 AM   #9
ppr:kut
Member
 
Registered: Aug 2006
Location: Netherlands
Distribution: Slackware
Posts: 361

Original Poster
Rep: Reputation: 93
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.
 
  


Reply

Tags
directories, rights, tmp, user


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Apache access forbidden to user dirs. Spudley Suse/Novell 1 12-29-2005 01:53 AM
Running super user commands as normal user mickyg Linux - Security 5 10-14-2005 07:25 PM
X won't login normal users (cannot write to /tmp) R00ts Linux - Software 6 09-03-2005 01:25 AM
Games runs slow as normal user, but fast as root user mcore Linux - Software 2 06-07-2004 11:11 PM
Squid proxy with user authentication and user rights duvanhorn Linux - Networking 0 08-07-2003 03:40 AM


All times are GMT -5. The time now is 05:57 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration