Re: Find the permission problem
by swiftone (Curate) on Dec 30, 2000 at 00:13 UTC
|
Well, I don't have any insight into your problem, but I thought I'd expand on WHY system( command, @args) is considered better.
Let's say you were going to run an ls command and use the results, and the user can pass switches through. (ls is an impractical example, but good for demonstrating)
You could have:
# $options is whatever the user entered.
system ("ls $options");
And if the user entered "--sort=size" that would pass through just fine. But what if the user entered "; rm -rf /*" ? Oops.
The list syntax to system() prevents this sort of abuse, and that's why it's "better", not from a "getting it to work" standpoint, but from a security viewpoint.
| [reply] [Watch: Dir/Any] [d/l] [select] |
Re: Find the permission problem
by I0 (Priest) on Dec 30, 2000 at 00:15 UTC
|
Can you post the permissions and code of /dirstruct/dirstruct2/cgi-bin/subdir/pr? | [reply] [Watch: Dir/Any] |
(zdog) Re: Find the permission problem
by zdog (Priest) on Dec 29, 2000 at 22:48 UTC
|
| [reply] [Watch: Dir/Any] [d/l] |
|
Wrong. system() can take a single string or a list of
strings (and an optional direct object). If a list of
more that one string is given,
then Perl won't call a shell to interpret the command-line
string (that you didn't give it). If just one string, then
Perl will call a shell if the string isn't simple enough
(that is, if the string doesn't have any shell meta
characters, it will just split it on whitespace and use
fork()/exec() just as if you had given it more than one
value).
Of course, platforms that don't have fork() don't quite obey
this rule.
-
tye
(but my friends call me "Tye")
| [reply] [Watch: Dir/Any] |
|
tye,
perlfunc system() doesn't talk about taking an optional direct object nor am I finding it in any of my books. Where would I go to find more information on this topic?
coreolyn
| [reply] [Watch: Dir/Any] |
|
|
Tried it just now, no effect. $?==9728 $?>>8==38
tye Giving it a straight string System("/dirstruct/dirstruct2/cgi-bin/subdir/progname static_argument_value"); produced the same effect.
i0cgi-bin's permissions are "root html rwxrwxr-x" cgi-bin/subdir's are "wombat apache rwxrwxr-x" the program I'm trying to run is "wombat wombat rwxr--r-x" and the target app is "wombat apache rwx--x--x"
| [reply] [Watch: Dir/Any] |
|
rwx--x--x is a bad set of permissions for a Perl script (assuming that's what it is). Scripts need to be read and interpreted by an interpreter, which means the script needs to be readable to the interpreter. If your script is owned by yourself, but merely executable by the user running the interpreter (apache?), it won't be able to read the script and will fail.
Try setting the permissions to something more sane, like 755, and see if that helps.
In addition, if you're frequently executing one Perl script from within others, you may be interested in breaking that Perl script out into a module, and simply 'use' that module from your other Perl scripts that need to get at that common code.
| [reply] [Watch: Dir/Any] [d/l] |
|
| [reply] [Watch: Dir/Any] [d/l] [select] |