running shell on a web server

Anyone have any experience running shell scripts (csh) on a web server? The object being to get anyone to use a simple HTML form to input data to the script, then have the script return its output as a web page.

It works except for the web server launching the script in a very restricted environment. I don't understand how to get the server to run the script with a proper PATH environment.

Lighttpd server on Ubuntu 9.10. No, I haven't gotten a lot of help on the lighttpd forums.

It's not a question of user rights, I've managed to get the script to have the rights to write output files to its current directory. It's just that without a $PATH, things like head or tail don't work because they'd need to be called like this /usr/bin/head

TIA

Reply to
a7yvm109gf5d1
Loading thread data ...

Well, you an cheat a bit to get started, then lookup adding the HTML headers:

formatting link

User 'nobody' likely doesn't have a path as such. It is right there where the page is.

User nobody has no right to be calling such binaries, haven't you looked at CGI security? You need a CGI security wrapper to allow safe runtime access. You're asking in the wrong place here.

Grant.

Reply to
Grant

snipped-for-privacy@netzero.com wrote: ...

Yes, that's right. When you're doing CGI, you can't count on any environment variables, so simply use absolute paths, as you've shown.

But there are form-fill-out scripts all over the web. What are you trying to accomplish that you can't? What's your attempt not doing that it should?

Couldn't you find a newsgroup more appropriate to web page programming?

Good Luck! Rich

Reply to
Rich Grise

And most of them are non-secure, that's why we read about drive-by downloads and junk -- web forms are easy to do, doing them correctly takes a little more thought.

Agree!

Grant.

Reply to
Grant

And the first thought should be to use something other than csh.

Languages where everything is a string and which revolve around textual substitution are particularly prone to injection attacks, which are the probably the most common type of vulnerability in CGI scripts (although the injection isn't necessarily in the language in which the script is written, but may occur when passing SQL to a database, in shell syntax when executing commands using a system()-like interface, or in the HTML returned by the script).

Use a real language. If you need to run external commands, use an interface which takes the arguments as a list of strings (like execve), not a single string (like system). And avoid eval()-type functions like the plague.

Reply to
Nobody

se

ent

d?

Thanks, but actually no. No one responded. There is too much background knowledge that is assumed that I don't have.

The script is a shell script. I didn't write it. It's a mess of greps and > that writes files and calls other scripts and executables. I just want it to run in a web browser the SAME way it runs as launched from a shell. It only outputs text. The whole thing is running on its own LAN, and has no access to the outside world. Is running a shell script but launched from a HTML form so far- fetched, so complex and revolutionary that it can't be done? All I'm having are some weird behaviors that no one seems to want to explain.

If I don't have a $PATH variable, why not? What do I set to change that behavior? That's all I want to know. Is it a user/group thing? Is it a lighttpd thing? Is it a CGI thing? I don't know, it's not clear, and no amount of googling has helped so far.

Reply to
a7yvm109gf5d1

Reply to
Grant

because

environment

trying

should?

programming?

$PATH is usually attached to a "user". And each "user" gets one individually. It describes the places to look for executable files. How it gets setup in any given environment varies quite widely.

This is SED, you would get much better answers from a Lighttpd or Ubuntu group.

Reply to
josephkk

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.