Cannot execute /bin/bash: Permission denied

I've never installed a SlackBuild script before, and I don't really know how it is supposed to be done, but I downloaded the truecrypt 4.3a slackbuild script from alien bob's site and ran it. It created a truecrypt tgz package in /tmp. I ran installpkg on that, and it installed. Maybe I did it wrong.

Immediately after running installpkg and before doing anything else at all, I tried to lock my KDE session because I was going to leave my computer for a while. It wouldn't lock. I logged out of KDE and tried to startx again and got a message "cannot execute startx: permission denied".

So I logged out completely and tried to log back in. Now I cannot login with my normal non-root account. I get "Cannot execute /bin/bash: Permission denied".

My root account is not affected. How can I determine what is wrong with my non-root account and fix it so I can login again?

root@localhost:/# ls -al /bin/bash
-rwxr-xr-x 1 root root 679620 2006-05-13 18:55 /bin/bash*

Not sure here. You have correct permissions on bash. Can you 'su' to your user from root? Can you do that and check what $SHELL is set to?

My first thought would be to uninstall truecrypt package and see what happens.

The command is su - username right?

I still get "Cannot execute /bin/bash: Permission denied"

I removed truecrypt package and it made no difference.

I had an earlier version of truecrypt installed, and it appears to still be installed. I compiled and installed it with the truecrypt install.sh script last year. It's version 4.2, and when I run truecrypt -V it reports version 4.2. Interestingly, that's what it showed after I did the slackbuild of 4.3a also.

I have two other non-root users on my system. I can't su to either of them.

My second user was logged on and KDE session locked. I tried to unlock, and I get an error message in a dialog box that says

Cannot unlock the session because the authentication system failed to work. 
You must kill kdesktop_lock (pid 23666) manually.

I'm reluctant to do that because the issues appears to be deeper than KDE. My logged out user can't logon at all and can't access /bin/bash.

Is truecrypt actually running right now? If so what happens if you kill it?

Sorry I can't be of more help, but it sounds to me like the installation script somehow messed up your file permissions...

Hopefully someone with more knowledge can help you out here.

truecrypt is running and I can't seem to kill it.

root@localhost:/tmp# ps ax | grep -i true
27411 ?        S<     0:00 [truecryptq/0]

What have to tried to kill it?

kill -s 9 27411

Yes, that's the kill command I used. Also just

kill 27411
kill -SIGKILL 27411

It won't die.

One other thing. I noticed that my /lib directory had permissions 710, which seemed odd. That is, -drwx--x---. I changed it to 755 and tried to login my non-root user again. This time I was able to logon (YEAH!), but I got a different error message:

-bash: fortune: command not found.

Could it be that maybe the truecrypt source compile and install or the slackbuild I ran afterwards hosed some other directory and file permissions?

Can someone who has a Slackware 11 stock install with 2.6.18 kernel (the one from test26.s) post the results of ls-al from the root directory (that is, the "/" directory)?

In general, should most of the system directories have permissions of 755? Is there a reference system somewhere that I can compare my possibly hosed permissions to?

echo $PATH

Maybe thats why it cant find fortune. I'm not using a stock kernel but the permissions should be the same:

drwxr-xr-x  21 root root   664 2007-06-23 20:26 ./
drwxr-xr-x  21 root root   664 2007-06-23 20:26 ../
drwxr-xr-x   2 root root  4272 2007-06-23 05:08 bin/
drwxr-xr-x   2 root root   336 2007-06-22 23:06 boot/
drwxr-xr-x  21 root root 15140 2007-06-23 22:51 dev/
lrwxrwxrwx   1 root root    20 2007-06-22 18:22 downloads -> /mnt/str1/downloads//
-rw-r--r--   1 root root    46 2007-06-23 00:16 ect
drwxr-xr-x  62 root root  5784 2007-06-23 20:26 etc/
drwxr-xr-x  10 root root   472 2007-06-23 03:44 home/
drwxr-xr-x   5 root root  3304 2007-06-23 05:04 lib/
drwxr-xr-x  16 root root   664 2007-06-23 17:44 media/
drwxr-xr-x  20 root root   512 2007-06-23 04:59 mnt/
drwxr-xr-x   4 root root   112 2007-06-12 21:56 opt/
lrwxrwxrwx   1 root root    19 2007-06-22 18:23 packages -> /mnt/str1/packages//
lrwxrwxrwx   1 root root    17 2007-06-23 00:20 phone -> /mnt/phone/phone//
dr-xr-xr-x 110 root root     0 2007-06-23 17:43 proc/
drwx--x---  13 root root   608 2007-06-23 22:31 root/
drwxr-xr-x   2 root root  5856 1999-03-27 20:40 sbin/
drwxr-xr-x   2 root root    96 2007-06-21 05:52 srv/
lrwxrwxrwx   1 root root     9 2007-06-22 07:08 str5 -> /mnt/str5/
drwxr-xr-x  11 root root     0 2007-06-23 17:43 sys/
drwxrwxrwt   7 root root   320 2007-06-24 00:02 tmp/
lrwxrwxrwx   1 root root    17 2007-06-23 00:19 usbpen1 -> /mnt/usb/usbpen1//
lrwxrwxrwx   1 root root    16 2007-06-23 00:20 usbpen2 -> /mnt/usb/usbpen2/
drwxr-xr-x  20 root root   584 2005-03-06 05:29 usr/
drwxr-xr-x  16 root root   504 1998-03-18 22:42 var/

root@localhost:~# echo $PATH

/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:
/opt/www/htdig/bin:/usr/lib/java/bin:/usr/lib/java/jre/bin:/opt/kde/bin:/usr/lib/qt/bin:
/usr/share/texmf/bin

And this is my root directory, which has some differences in permissions from yours.

root@localhost:/# ls -al
total 32
drwxr-x---  27 s     users   664 2007-06-23 18:23 ./
drwxr-x---  27 s     users   664 2007-06-23 18:23 ../
drwx------   3 root  root    176 2006-08-20 17:04 .tor/
drwxr-xr-x   2 root  root   3976 2006-10-30 00:41 bin/
drwxr-xr-x   4 root  root    632 2006-10-30 22:58 boot/
drwxr-xr-x  23 root  root  15460 2007-06-23 11:51 dev/
drwxr-xr-x  54 root  root   6008 2007-06-23 11:38 etc/
drwxr-xr-x   7 root  root    168 2006-12-02 16:42 home/
drwxr-xr-x   7 root  root   4384 2007-06-23 11:36 lib/
drwxr-xr-x   3 root  root     72 2004-08-12 07:34 man/
drwxr-xr-x  16 root  root    600 2006-10-30 00:19 media/
drwxr-xr-x  16 root  root    416 2006-09-25 22:09 mnt/
drwxr-xr-x  12   500 root    736 2006-03-25 19:06 netpbm-10.33/
drwxr-xr-x   6 root  root    144 2007-03-30 23:31 opt/
dr-xr-xr-x 125 root  root      0 2007-06-11 21:48 proc/
drwxr-xr-x  10   155 users   888 2006-06-03 23:11 procmeter3-3.4e/
drwx--x---  27 root  root   1888 2007-06-23 11:44 root/
drwxr-xr-x   2 root  root   7192 2006-08-16 15:20 sbin/
drwxrwxr-x   9   555   555  3568 2006-07-06 08:56 sg3_utils-1.21/
drwxr-xr-x   3 root  root     72 2004-08-12 07:34 share/
drwxr-xr-x  11 root  root      0 2007-06-11 21:48 sys/
drwxr-xr-x   2 59930    69   624 2000-08-04 11:22 tidy4aug00/
drwxrwxrwt  57 root  root   2416 2007-06-23 15:36 tmp/
drwxr-x---  18 root  root    544 2007-06-23 11:36 usr/
drwxr-xr-x  17 root  root    480 2006-12-16 23:30 var/

Ok looks normal and probably doesn't affect original problem. I did once install a package that messed up some file permissions.

You may want to try some other sig specs with kill. kill -l will list them. I seem to remember kill -s 19 is effective. If that doesn't work maybe you need to find out where truecrypt is starting from, stop it there, then reboot.

OK, so far I've changed /lib and /usr to have 755 permissions. Now I can logon my non-root users, the fortune command executes at logon, and I can startx. But KDE says that KDEinit can't find the firefox executable when I try to start firefox, so I clearly have some other permissions that have gotten hosed.

I think it's just a matter of figuring out what permissions need to be changed now. It would be nice if there were some way for me to just go set all the original distribution directories back to their stock permissions automagically, but I guess I'll have to do it the hard way.

Bummer. I wish I understood what happened to clobber all my permissions.

I believe I've fixed all the damage and I seem to be back to normal now. Thank you dive and mattydee.

NOTE: Just to be clear - the file system permissions damage was my fault, not the fault of the SlackBuild that I used. I simply didn't understand until this instructive episode how a umask of 027 for the root account, which is what is normally used for building and installing scripts that are intended to be world accessible, would affect file system permissions. Needless to say, my root umask is now 022.