Bash scripts not executing... bad interpreter?

danthehat

Any bash script or sh script on normal users on my machine fails execution with this error message:

platojones · Posted: Mon Mar 26, 2007 6:43 pm Post subject:

[removed for stupidity of that response] :roll:

sdfischer · n00b Joined: 18 Feb 2007 Posts: 3

Perhaps you are trying to run an executable on a filesystem that you have no executable permissions on (noexec) -- but that doesn't explain root being able to run it -- I would investigate filesystem permissions.

Good Luck

danthehat · Posted: Tue Mar 27, 2007 1:09 pm Post subject:

If my filesystem permissions were somehow altered, then that would mean I would not be able to execute anything else in my $PATH, which is not the case. I can evoke both of the shells and I use Bash as my default shell (as do most people, I imagine).

Having exhausted all of my resources, I haven't a clue how to deal with this situation. I would appreciate any further input.

Thanks.

Jim6 · Tux's lil' helper Joined: 08 Apr 2005 Posts: 102

Just posting to say - you're not on your own!

I've the same problem here -
"sh" on it's own works fine
"sh <script>" works fine
"./<script>" fails

I'll let you know if I come across a solution

Edit: solved!
It's almost certain that you don't have the "exec" flag set on whatever filesystem you're running the scripts.

cat /etc/mtab to find out, then change the relevant /etc/fstab line and remount. Happy hunting!

Edit2: Oh, and remember that the "user" flag implies "noexec".

danthehat · Posted: Sun Apr 08, 2007 6:30 pm Post subject:

The problem is localized to the /home filesystem (/dev/hdb1). For some reason, I cannot execute binaries or bash files there. I am almost positive this has something to do with whatever grSecurity did to my system, as I had a similar problem when I didn't mount my iPod with the exec flag on my other system.

Are there configuration files that dictate which folders can have executables in them?

Contents of mtab:

danthehat · Posted: Sun Apr 08, 2007 7:23 pm Post subject:

Solved!

GrSecurity was screwing me up, but in a way I didn't consider. After considering and reconsidering the filesystem permissions as the source of the problem, I determined that if the root filesystem was exec and the /home filesystem had identical permissions, then some outside variables were influencing the situation. After confirming that I had removed userland rsbac controls from my system, I turned to the kernel configuration. I discovered that Trusted Path Execution was on and restricting accounts in the users group... which my non-root user was in. I used sysctl to change the untrusted group to a new group that I could manage, logged out and logged back in, and what do you know... My little test bash script said helloes.

Just goes to show... Before enabling any kernel module, you should read the documentation. It's a bit of hefty reading, but worth the headache in the end.

Thanks for your input, guys.