I have a perl CGI that calls a suidperl script that broke in the update to
slink. What is suppoed to happen is the CGI gets the data from the web page,
rigorously checks it for safeness and then system()'s a root suidperl script
to do the work. It used to work under potato, but now under
On Wed, 08 Mar 2000 17:32:58 -0600, you wrote:
I have a perl CGI that calls a suidperl script that broke in the update to
slink. What is suppoed to happen is the CGI gets the data from the web page,
rigorously checks it for safeness and then system()'s a root suidperl script
to do the work.
In message [EMAIL PROTECTED], Marc Haber writes:
On Wed, 08 Mar 2000 17:32:58 -0600, you wrote:
I have a perl CGI that calls a suidperl script that broke in the update to
slink. What is suppoed to happen is the CGI gets the data from the web page,
rigorously checks it for safeness and then
Thus spake Ted Cabeen ([EMAIL PROTECTED]):
I have a perl CGI that calls a suidperl script that broke in the update to
slink. What is suppoed to happen is the CGI gets the data from the web page,
rigorously checks it for safeness and then system()'s a root suidperl script
to do the work.
In message [EMAIL PROTECTED], Adam
Shand writes:
following error in my error.log: Can't do setuid
are you running under suexec? that is the only apache security mechanism i
am aware of which restricts suid scripts/binaries. if you are there is no
way around this, disable suexec.
I'd like to
I'd like to run without suexec, if possible, since I have absolutely no
need for it.. How would one arrange that with the debian Apache
install?
you have to explicitly enable suexec for each virtual domain you host. if
you have a directive in your config called user and/or group then you
6 matches
Mail list logo
