Re: chmod symlink



JohnF <john@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:

[...]


Yup, that's what I'd feel pretty comfortable concluding
from what I observationally see:
o I definitely see the log file always get written.

Ergo: Your problem is not that the server refuses to execute the
program because of 'a permission problem'.

o The program runs when you point a browser directly to
its executable image in any (sub)directory I've tried,
as long as the cgi image is chmod 755.

o Replace any cgi image by a symlink to any other copy
of the cgi that you leave in place, and you get
a 500 error pointing your browser to the symlink.

o Or chmod 777 any cgi image itself, and it fails
identically to the symlink failure.

'Identicially' here meaning "it's also reported as internal server
error". And this covers a lot of wildly varying stuff.

o And, again, any failure at all always writes the logfile.

Assuming this is literally true, the permissions likely don't matter
at all: They are checked before or at latest when the corresponding
exec is executed and don't figure afterwards.

[...]

I think you should take your questions over to a newsgroup about the web
server, it's probably something with its configuration.

Sure, I'd bet good money apache's httpd.conf could be edited
to allow 777 symlinks to work.

Despite John Tsiombikas' best efforts to obscure this fact, the
permissions of a symlink are always 777 and they are never used
because a symlink can neither be opened nor executed.

You have some error in your code and you will need to determine what
this code is actually doing (as opposed to what you believe it does)
in order to find and eliminate the cause. Theorizing about some
situation based on being ignorant about it (if you knew what the code
is doing, it should work, don't you think so?) is not a suitable
debugging methodology.
.