[SOLVED] Lost permissions for startx (and others) after Tor installation

thethinker · 05-17-2014, 01:06 AM

I'm running 13.37 on my old laptop, and I thought I might mess around with Tor. So I installed Tor and Vidalia via SlackBuilds.org, no errors and they ran fine (needed to run Vidalia as root - maybe or maybe not relevant). In any case, my username seems to have lost many permissions - for instance, I cannot run startx or man (maybe others - just noticed these).

Everything seems to run fine under root but not as a regular user (standard "command not found" message). Can someone give some advice on debugging this or determining which permissions I'm supposed to have to restore? I guess maybe my groups got all screwy - maybe some advice about checking those?

In case it matters, I ran the following commands before installing Tor:

Code:

groupadd -g 220 tor
useradd -u 220 -g 220 -c "The Onion Router" -d /dev/null -s /bin/false tor

(this was as directed by SlackBuilds). As I understand it, this should not have affected my current user settings, but maybe something unexpected happened.

Any Advice?

Didier Spaier · 05-17-2014, 01:17 AM

First, make sure that's actually a permission problem.

What gives "echo $PATH" as a regular user? And can you access the commands typing their absolute paths, e.g. /usr/bin/startx or /usr/bin/man?.

Then, make sure that's not the binaries' permissions that changed. What gives "ls -l /usr/bin/startx", "ls -l /usr/bin/man", for instance?

ponce · 05-17-2014, 01:48 AM

maybe the root shell you used to build the packages has set/inherited a wrong umask: check it with the command "umask", should be 0022.

this should manifest with wrong directory permissions after installing the generated package, for example, for /usr or /usr/bin or /etc (they should be all 0755), or others...

you can also explodepkg (while in a temp folder) the package you installed and check for wrong directory permissions there.

Quote:

Originally Posted by thethinker

So I installed Tor and Vidalia via SlackBuilds.org, no errors and they ran fine (needed to run Vidalia as root - maybe or maybe not relevant)

maybe I'm understanding this wrong, but you have to run every SBo's *.SlackBuild as root (and in a root login shell, obtained with "su -"), check the FAQ.

thethinker · 05-17-2014, 10:49 AM

Thanks for helping out guys:

Didier:

Code:

$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/lib64/java/bin:/usr/lib64/kde4/libexec:/opt/kde3/lib64/qt3/bin:/opt/kde3/bin:/usr/lib64/qt/bin:/opt/sage:/usr/share/texmf/bin:.

which looks about right to me, but check out this:

Code:

$ cd /usr/bin
-su: cd: /usr/bin: Permission denied

That is unexpected behavior right? In other words, no, I cannot access /usr/bin/*. The permissions of the binaries look fine (at least to me...)

Code:

# ls -l /usr/bin/startx
-rwxr-xr-x 1 root root 4462 Nov 13  2010 /usr/bin/startx*

ponce:
Don't know much about umask, but I guess this is correct? (same result when run as user)

Code:

# umask
0022

I don't know too much about the explode package - or what to expect - but after doing it (as root) I get this in the directory:

Code:

vidalia$ ls -la
total 16
drwxr-xr-x 4 root    root  4096 May 17 01:29 ./
drwxr-xr-x 3 MYUSER  users 4096 May 17 11:41 ../
drwxr-xr-x 2 root    root  4096 May 17 01:29 install/
drwxr-xr-x 6 root    root  4096 May 17 01:29 usr/

and tor:

Code:

tor$ ls -la
total 24
drwxr-xr-x 6 root    root  4096 May 15 14:21 ./
drwxr-xr-x 4 MYUSER  users 4096 May 17 11:42 ../
drwxr-xr-x 5 root    root  4096 May 15 14:21 etc/
drwxr-xr-x 2 root    root  4096 May 15 14:21 install/
drwxr-xr-x 6 root    root  4096 May 15 14:21 usr/
drwxr-xr-x 5 root    root  4096 May 15 14:21 var/

So similar results there. I dunno if it matters, but after I explodepkg these, I cannot do anything like "mkdir" inside these directories (which are in my home folder). That might be expected behavior though.

As far as how SlackBuilds rolls, you've got it right. You need to 'su -c' the *.SlackBuild, then installpkg "/tmp/blah-SBo-blah.tgz" as root as well. I do this all the time, never had this craziness! When I said I needed to "run as root" I mean that the first time I actually started vidalia, I got some error messages suggesting it had some permission issues, so I ran it as root and it worked as expected.

Any of that help? I really appreciate it guys,

thethinker · 05-17-2014, 11:13 AM

Ok, I don't know what the permissions are supposed to be exactly, but they seem correct to me:

Code:

$ stat /usr/bin
  File: `/usr/bin'
  Size: 102400    	Blocks: 208        IO Block: 4096   directory
Device: 802h/2050d	Inode: 5505073     Links: 2
Access: (0700/drwx------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2014-05-17 01:44:20.563999961 -0400
Modify: 2014-05-17 01:39:11.498999993 -0400
Change: 2014-05-17 01:39:11.498999993 -0400
 Birth: -

Code:

# stat /usr/bin/startx
  File: `/usr/bin/startx'
  Size: 4462      	Blocks: 16         IO Block: 4096   regular file
Device: 802h/2050d	Inode: 5543744     Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2014-05-17 01:21:03.983000268 -0400
Modify: 2010-11-13 13:59:36.000000000 -0500
Change: 2011-12-11 16:32:07.592419905 -0500
 Birth: -

ponce · 05-17-2014, 11:15 AM

Quote:

Originally Posted by thethinker

Code:

$ cd /usr/bin
-su: cd: /usr/bin: Permission denied

That is unexpected behavior right? In other words, no, I cannot access /usr/bin/*.

so see which are /usr/bin directory ownership and permissions with "ls -la /usr/": those (and who knows whatever else) look borked.

Quote:

As far as how SlackBuilds rolls, you've got it right. You need to 'su -c' the *.SlackBuild, then installpkg "/tmp/blah-SBo-blah.tgz" as root as well. I do this all the time, never had this craziness!

but you really shouldn't: as I said before (and listed in the FAQ) you should open a root login shell with "su -l", not use "su -c".

Quote:

When I said I needed to "run as root" I mean that the first time I actually started vidalia, I got some error messages suggesting it had some permission issues, so I ran it as root and it worked as expected.

you shouldn't have done that too: in the README.SBo of vidalia (that you should have read) is indicated a fix to avoid running it as root.

thethinker · 05-17-2014, 11:41 AM

Quote:

Originally Posted by ponce

so see which are /usr/bin directory ownership and permissions with "ls -la /usr/": those (and who knows whatever else) look borked.

I think that's what I did above - my /usr/bin is 0700 and my /usr/bin/startx is 0755. /usr/bin should be something like 0755 right, for execute and reading? I'm trolling around looking for what the default permissions are for /usr/bin - but yeah you're right what *else* could have been changed?

Quote:

Originally Posted by ponce

but you really shouldn't: as I said before (and listed in the FAQ) you should open a root login shell with "su -l", not use "su -c".

Oh my God I did not know that - I've been doing su -c for SlackBuilds this entire time! Reading the HOWTO I see it very clearly written as "su -l" - where the heck did I get that "su -c" was ok?

Quote:

Originally Posted by ponce

you shouldn't have done that too: in the README.SBo of vidalia (that you should have read) is indicated a fix to avoid running it as root.

In my defense, the README in the version of Vidalia for 13.37 does not include that one little line about running as root. Obviously I'll follow that, thanks for pointing it out.

ponce · 05-17-2014, 12:24 PM

try a

Code:

chmod 0755 /usr/bin

thethinker · 05-17-2014, 01:33 PM

Quote:

Originally Posted by ponce

try a

Code:

chmod 0755 /usr/bin

Fixed!

So the problem was running Vidalia as root, it changes the permissions. The fix is given in the updated README vidalia readme file.

Thanks to you both for helping!