-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2007-05-09 at 20:35 +0200, Caisa Persdotter wrote:

Thanks, but it still gives the same message. I've tried to run ./configure in several directories with untared soursces but get the same result. It worked fine before reinstallation.

Issue the command "mount" and see if the partition is mounted "noexec". If so, correct. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGQhbCtTMYHG2NR9URAoawAJ9R0L6Wx4P2lU8hlfrtmAmC8/WujACcCF5s ZED9FqBfuOEy5dtrnutbTDM= =7QEi -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wednesday 09 May 2007 12:38, Jim Cunning wrote:

On Wednesday 09 May 2007 11:45:11 Carlos E. R. wrote:

...

The Wednesday 2007-05-09 at 20:35 +0200, Caisa Persdotter wrote:

...

Thanks, but it still gives the same message. I've tried to run ./configure in several directories with untared soursces but get the same result. It worked fine before reinstallation.

Issue the command "mount" and see if the partition is mounted "noexec". If so, correct.

I think your problem is that "/bin/sh" doesn't exist. For example:

No Unix system can run without its primary shell. It's invoked all over the place to interpret command lines and run scripts, not just for interactive user sessions. It would be very odd for the shell not to be executable, but since root can still execute files without there x bit (am I remembering that right?), most critical system functions would still work even if the system were almost entirely crippled for ordinary (non-root) users. Carlos' guess about the file system holding /bin being mounted "noexec" is a good one. It seems like the most likely explanation.

...

Jim

Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wednesday 09 May 2007 17:04, Carlos E. R. wrote:

The Wednesday 2007-05-09 at 14:34 -0700, Randall R Schulz wrote: ...

...

It would be very odd for the shell not to be executable, but since root can still execute files without there x bit (am I remembering that right?),

Er... I dont think so... you can always execute a script that is not marked executable by doing "sh scriptname"; this is true for root and normals users, and it can be the bash shell, or any other interpreter.

I remember what the exception was (and I confirmed it this time). For ordinary users, the permissions used to grant or deny any particular access attempt is fixed based on whether the file's UID matches that of the request process, the GID matches or neither of the above. In the first case, the owner bits are used, period. In the second case, only the group bits are used and in the last case, the "other" bits are used. But for root it's a bit more complicated. For read and write access, root simply always gets access. For directory scanning, again, root gets access even with no execute bits, assuming the target of the access is actually a directory. (Ordinary users need execute access to get the kernel to look up a file in a directory, even if they have read access and can see the names of entities within that directory--in fact, they don't need read access, if they have execute access and know the name of an entity in the directory, they can access it). But to execute a file, root needs an execute bit, but it may be in any of thethe three groups (owner, group or other). To wit: # id uid=0(root) gid=0(root) groups=0(root) # cp /bin/sh shell # chmod 444 shell # ll shell -r--r--r-- 1 root root 490716 May 9 17:24 shell* # ./shell -bash: ./shell: Permission denied # chmod 445 shell # ll shell -r--r--r-x 1 root root 490716 May 9 17:24 shell* According to the rules applied to ordinary users, this "shell" would not now be executable, but for root, any execute bit will do: # echo $$ 12019 # ./shell # # Now in a sub-shell: # echo $$ 10501

...

...

Carlos' guess about the file system holding /bin being mounted "noexec" is a good one. It seems like the most likely explanation.

Actually, I was thinking of the partition holding the configure script; for example, "/home". My fuzzy memory says I heard of that in this very list some other time ;-)

Ah. Even more probable.

-- Cheers, Carlos E. R.

Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wed, May 09, 2007 at 06:42:53PM +0200, Caisa Persdotter wrote:

I had to reinstall Suse 10.2 after a hardware upgrade. And suddenly I can't compile programs. Here's the out put:

drivel-2.0.3 > ./configure -bash: ./configure: /bin/sh: bad interpreter: Permission denied

On Wed, May 09, 2007 at 12:38:59PM -0700, Jim Cunning wrote:

[jcunning@hipparcos test]$ cat test.sh #!/bin/nosuchshell echo test [jcunning@hipparcos test]$ ./test.sh bash: ./test.sh: /bin/nosuchshell: bad interpreter: No such file or directory

"Permission denied" is very different from "No such file or directory" :) So this is probably a dead end.. Caisa, I suggest checking first for AppArmor rejection messages. There should not be any, unless you are trying to profile / or have already profiled ./configure, or /bin/sh (bad idea!) or your login shell (via sshd? getty? etc?) Check /var/log/messages or /var/log/audit/audit.log for messages that look like this: type=APPARMOR msg=audit(1174508205.298:1791): REJECTING r access to /bin/ (ls(16552) profile /tmp/ls active /tmp/ls) If you find them, write back :) If you don't find them, then I would recommend to use strace to find this problem: strace -o /tmp/configure.output ./configure Look through the configure.output for EPERM or EACCES error returns and then start looking back up in the strace output for something that looks fishy. :) Hope this helps

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-05-10 at 08:40 +0200, Caisa Persdotter wrote:

Thanks for all the help on this issue.

It turned out that I, during the install, had played around with the settings in fstab that I probably shoudn't have touched. Now that I've resored the defaults everything works fine.

And what settings had you used that failed? We are curious ;-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGQvCetTMYHG2NR9URAkdEAJ9oeVAm7Gc/Wn0SocCEjwMWPnJ+DgCgkRlV C5m/z2X0wA6tc1cuaTnY6QQ= =EC14 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org