|
Germanic Lexicon Project
Message Board
|
|
|
Author: Sean Crist (Nuance Communications)
Email: kurisuto at panix dot com
Date: 2008-11-19 15:08:43
Subject: Re: A couple of updates
755 means "I, the owner of the script, can read, write, and execute it. Everybody else can read and execute it, but not write to it."
The first digit indicates owner privileges; the second indicates group privileges; and the third indicates privileges for everybody else. So, the final 5 means that everybody on the system can read and execute the script.
In this particular case, since the apache user belongs to the group which owns the B script, it's the second digit that matters. 7 means "can read, write, and execute". (Really 5 should be enough-- read and execute-- but 7 won't hurt.)
Just to double check, I did temporarily set the permissions on the B script to 777 (everybody can do everything: read, write, and execute), but the B script is still failing when the cgi script invokes it.
The permissions seem to be OK. Without being able to see the error logs, I really can't think of what the nature of the failure could be.
--Sean
> I offer this snippet from an advice page, for what it is worth:
>
> "Perl CGI scripts should have limited permissions. In most cases, Perl scripts should be owned by your user account, and have permissions of 755. If your web server is setup with strict permissions, scripts that do not have a permission setting of 755 will not be run. Instead a "Premature end of script headers" error will occur. If you are getting these errors, this is the first thing you should check."
>
> Many other pages treat 755 as the standard for Perl scripts, but I have not found any real discussion of why the final 5 is necessary. Must be worth a try, though!
>
>
> > I am really stuck on this. I just tried again and ran into the same dead ends.
> >
> > Part of the problem is that I don't have permissions to see the error logs to truly find out what is going on. I've just written again to see if the kind of warnings I need can be logged to a separate error log file.
> >
> > The general form of the problem is this:
> >
> > There are two scripts; let's call them A and B. Script A is a CGI script. Script B is a separate, free-standing Perl program. A invokes B during A's execution.
> >
> > This worked fine up until the sysadmins changed something back in August. Now, when A invokes B, B somehow fails to run.
> >
> > It doesn't make sense, because the permissions should be fine. The "apache" user belongs to the same group which owns B (www-glp). B has its permissions set so that members of the same group can read and execute it (permissions 770). CGI script A can certainly open and read B as a data file and print its contents out to the web page, for example; I determined this.
> >
> > All of the problem we're having are due to this general category of problem. If anyone has any suggestions, please let me know. I'm really stuck.
> >
> > --Sean
> >
> >
> > > Any further news on this?
> > >
> > > >
> > > > 1) I just took another lengthy stab at trying to fix the broken parts of the project. There are some clues which just aren't making sense. I've asked for further help. I just wanted everyone to know that this is not forgotten.
> > > >
> > >
> > > >
> > > > Thanks for everybody's patience.
> > > >
> > > > --Sean
>