the difference between binary file and ASCII file

hello,

if I have a unix shell script with permission ---x--x--x,
how can a unix shell detect that it is not an execuable binary 
application and gives an error message  "permission denied"?

Thanks,

Peter

in comp.unix.shell i read:


on most systems an executable script must also be readable.

-- 
a signature

That is done at kernel level. The kernel first checks your permission to 
execute some file. Then get its header and if it is a binary executable, 
run the code. Otherwise, if it is some shebang (#! path stuff) it 
actually run, in user mode, the following command "path stuff 
your-file". As the program specified by "path" tries to read the file 
before interpret it, the permission denied is issued.

file ~user/foo.mk with --x--x--x perms and contents:
#! /bin/make -f
all: ; echo all

you try: exec ~user/foo.mk
kernel checks 'x' flag, ok, then loads ~user/foo.mk, detects #! and try 
to run as :
$ /bin/make -f ~user/foo.mk

-- 
carlos **  http://www.**--****.com/ 

2004-01-14, 08:05(+00), peter:
[...]
[...]

If it is a dynamically linked object. You can see if your
dynamic linker as options to not execute the file but instead to
write some informations about it:

on HPUX: _HP_DLDOPTS=-ldd
on Linux: LD_DEBUG=help
      or  LD_TRACE_LOADED_OBJECTS=1
      or  LD_TRACE_PRELINKING=1
(env vars)

~$ ls -l ls passwd
---x--x--x    1 chazelas users       61144 2004-01-14 09:40 ls*
---x--x--x    1 chazelas users        2260 2004-01-14 09:44 passwd*
~$ LD_TRACE_LOADED_OBJECTS=1 ./ls
        librt.so.1 => /lib/librt.so.1 (0x40021000)
        libc.so.6 => /lib/libc.so.6 (0x40033000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x40168000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
~$ LD_TRACE_LOADED_OBJECTS=1 ./passwd
zsh: permission non accord: ./passwd
(126)~$

See your dynamic linker man page (dld.sl, ld.so, ld-linux.so...)
You may also play with LD_PRELOAD to override the _init or
main functions.

If the file is a valid binary file but statically linked, it
will get executed...

-- 
Sthane                      ["Stephane.Chazelas" at "free.fr"]

I think there might be a loop.
#!/bin/bash
printf("hello\n");

with permission --x--x--x.
bash kernel will send it to system() or exec() for executing if
the file is not readable (there is a chance that the file might be 
binary). However, if it is some shebang #!/bin/bash, system() through sh 
which calls exec() will send it to bash.

Again, bash kernal cannot read this executale code, it will send it back 
to system() since bash itself cannot tell if it is binary code or not.

Not sure how shell handles this dilema.

thanks,

Peter

hi again,
there's no loop.
Using your example and some pseudo-code:

$ cat > xpto.sh
#! /bin/bash
echo "hi"
^D
$ chmod 111 xpto.sh
$ ./xpto.sh
[bash: exec xpto.sh]
[kernel: loads header, detects shebang, run /bin/bash path/xpto.sh...]
[/bin/bash: open xpto.sh, permission denied]

Bash, or some other program, must open files before doing anything. You 
are confusing a "bash file" with "bash -c file". The 2nd would in fact 
cause a loop, i.e. bash was to execute file and the same mechanism would 
occur again, but the kernel actually issues the first.

-- 
carlos **  http://www.**--****.com/ 

The shell doesn't detect this.  This is a job for your
system's kernel, which the shell will shell will
call via exec().

First, the kernel checks to make sure that you do in fact
have permission to execute the file.  Then, if you do,
the kernel looks for the "#!" characters as the first
two bytes.  If it finds them, it is interpreted, and the
first line after the "#!" is the pathname of the interpreter.
The kernel loads the interpreter into memory, passing it the
name of the file as a a parameter.  If file does not begin "#!",
the kernel looks to see if the file is valid binary format
(exactly what this entails varies from system to system).  If
it is a valid binary, it loads into memory and starts it
running.  If neither begins with "#!" nor is a valid binary,
the kernel assumes it is a script for the current shell.  It
loads the current shell into memory and starts it running,
passing it the name of the file as a parameter.  Since all
this code runs in the kernel it doesn't care about your file
permissions, and that's why you can run binary programs you
can't read.  But with interpreted files, the kernel actually
loads the interpreter.  The interpreter runs as user code,
so it must have permission to read the script.

             Chris Mattern