The AFS System Administrators Guide section on Unix mode bits says that
the owner "x" bit should be enough to execute a binary file.
Of course, this wouldn't be true for any type of shell script since the
shell needs to read the file, and the shell runs in user-space. For
binary files, the kernel is responsible for reading the file so it can
implement the "--x" permission scheme.
At the PSC, it was also noticed that the file needs to be cached in
order for the "--x" permissions to work properly. In an earlier version
of AFS, it was apparently working correctly but it broke under a recent
version of AFS 3.4 for alpha_osf32c.
We used "--x" mode bits on some licensed software binaries to ensure
that they couldn't be copied. Of course, root users can read the files
out of the cache but that's no worse than storing them locally.
Joe Jackson,
Pittsburgh Supercomputing Center.
Excerpts from internet.info-afs: 17-Dec-96 Strange behavior of user bi..
by [EMAIL PROTECTED]
> I'm having some strange interactions with the permissions bits in
a execute
> file. The situation is the following:
>
> -I have a backup file x.bff
> -I do a restore -f x.bff ./llctl
> -the permissions are ---x--x--x, just execute.
> -I try to execute the file and I'm sucessfull
> -If I do a fs flush ./llctl them I can't execute the file anymore.
>
> Looks like the problem is when the file is cached the r bit is
ignored and
> I'm able to execute the file, what doesn't happen if the file isn't in the
> cache. This is a strange behavior because I'm used to have to put a read
> to be able to execute a file (even a binary one). I had the same behavior if
> I execute the file and then change the permission.
