|
Grex > Coop11 > #51: Enabling CGI scripts for Grex users | |
|
| Author |
Message |
| 25 new of 59 responses total. |
scg
|
|
response 21 of 59:
| 
Dec 7 04:35 UTC 1998 |
CGI programs run by the server getting a request from a web browser, so the
CGI program doesn't necessarily know what page caused it to be run.
|
remmers
|
|
response 22 of 59:
|
Dec 7 10:36 UTC 1998 |
The suggestion in resp:19 is technically feasible to implement,
but I doubt we'd want to do it, as it moves membership away from
"donation" and toward "payment for services".
|
scott
|
|
response 23 of 59:
|
Dec 7 11:47 UTC 1998 |
I think it would be cool to offer all sorts of services, but I don't
think we can afford to do that.
In the future we are very likely going to have to decide whether to cut
certain services, when popularity exceeds our capacity. I'd rather we
didn't add to what we offer, just to postpone that sort of decision. We
give out a lot already.
|
devnull
|
|
response 24 of 59:
|
Dec 10 11:21 UTC 1998 |
It seems to me that having some limit on cgi hits which would be enforced
by the honor system, much the way we handle disk space, would probably work...
(Whether grex has the capacity to deal with cgi at all is a completely
different question, of course...)
|
srw
|
|
response 25 of 59:
|
Dec 17 03:37 UTC 1998 |
In response to the first paragraph of Marcus's resp:14 :
(1) if we ever did allow users to write their own CGI programs, those
programs would only be run as the user, never as "nobody".
(2) CGI programs installed by the staff are run as "nobody" today, but
this ought to be changed to another nobody-like ID, such as httpd.
Under these conditions, I believe that the only purpose of limiting
user-written CGI is to limit the kinds of services we make available
over the web. This may indeed be a valid reason, but it is not a
security reason.
|
davel
|
|
response 26 of 59:
|
Dec 17 11:29 UTC 1998 |
Way back somewhere, someone indicated that CGI programs are prone to
exploitable holes which might allow others to gain access to a user's account.
Assuming that's so: on the one hand, it's reasonable to hand users the means
to do this; but on the other hand, it might generate enough staff work to make
us want to forbid CGI.
That's not precisely a security reason, but it's not just "to limit the kinds
of services we make available over the web", either.
I'm not in a position to evaluate how pressing a concern this is, myself.
|
devnull
|
|
response 27 of 59:
|
Dec 20 05:40 UTC 1998 |
The fact that a user can create a buggy cgi that might put that user's
account at risk doesn't really bother me that much. Users can already do
other things to put their account at risk (like telling others their password),
and so I think that clearly warning people ought to be adaquate. People
who know how to write secure cgi's should lose because we're concerned about
other people's cluefulness.
Because grex allows anyone to run newuser, there's no new risk to the system
as a whole if some random cracker can gain access to some non-root account.
|
mdw
|
|
response 28 of 59:
|
Dec 20 23:47 UTC 1998 |
Yes, but grex *also* has a responsible to people to make sure that other
people can't access their mail, private files, etc. Obviously, there is
only so much we can do on this score (we can't protect against human
stupidity), but we do want to make sure that the *system* software that
implements user cgi's has no holes, and the tools exist and are well
documented so that people are not tempted to create insecure cgi
scripts.
|
sev
|
|
response 29 of 59:
|
Dec 22 18:44 UTC 1998 |
You could create a perl library for users to implement into their script with
all the counter-measures so the user wont have to worry about programming
protection agains security holes themselves
|
mic
|
|
response 30 of 59:
|
Mar 21 07:39 UTC 1999 |
You'll regret allowing CGI access.
|
ryan
|
|
response 31 of 59:
|
Mar 31 15:53 UTC 1999 |
This response has been erased.
|
aruba
|
|
response 32 of 59:
|
Mar 31 18:53 UTC 1999 |
How hard would it be to add that as a command you can give while waiting in
the telnet queue?
|
ryan
|
|
response 33 of 59:
|
Mar 31 19:50 UTC 1999 |
This response has been erased.
|
prp
|
|
response 34 of 59:
|
Apr 2 05:57 UTC 1999 |
(big) If I understand this, allowing users to run CGI scripts is
equivalent to allowing robots.
It would be reasonable to allow forms on web pages, and collect
all the data in a file. The user could then run whatever to
process the file.
It would also be reasonable to collect E-mail, as long as it is
sent to the owner of the web page.
|
remmers
|
|
response 35 of 59:
|
Apr 2 17:56 UTC 1999 |
CGI isn't quite equivalent to bots. A bot runs all the time; a CGI
script runs only when somebody clicks on something that activates it.
If I understand what you mean by "collecting E-mail", it's already
possible. The owner of the web page can put a <mailto:...> link on it.
Anybody can then click on the link to send the owner mail.
|
prp
|
|
response 36 of 59:
|
Apr 2 23:06 UTC 1999 |
Well, a CGI script wouldn't get started when Grex boots, but it would
the first time anyone, not just the owner, activates it. It could
then run forever, or at least until the system goes down.
|
davel
|
|
response 37 of 59:
|
Apr 3 14:21 UTC 1999 |
Or, quite probably, until the kill-orphans script kills it.
|
ryan
|
|
response 38 of 59:
|
Apr 3 14:21 UTC 1999 |
This response has been erased.
|
ryan
|
|
response 39 of 59:
|
Apr 3 14:24 UTC 1999 |
This response has been erased.
|
prp
|
|
response 40 of 59:
|
Apr 3 23:41 UTC 1999 |
So, what exactly is an orphan? And why do you need a script to kill them?
My guess would be that an orphan is a task/job/process with no connection
to a terminal and presumably a person watching it. But in that case, I
would assume that when a connection closes, the device driver gets notified
from the Internet and ends things. No need for an orphans script.
|
remmers
|
|
response 41 of 59:
|
Apr 4 12:35 UTC 1999 |
You're pretty much correct about what an orphan is. But your assumption
about closed connections is wrong. Under Unix, you can arrange to run a
process "nohup" -- i.e. to ignore that the connection has closed. Then
the process continues to run even after its controlling terminal has
gone away. That behavior is what makes unattended bots possible. Grex
has been running a "kill-orphans" task for a number of years now to
catch such things. Presumably, it would continue to catch them if
they're running as CGI's.
|
prp
|
|
response 42 of 59:
|
Apr 4 15:58 UTC 1999 |
I remember some system from way back when, where when a connection was
lost, the task was suspended for 30 minutes. If the owner logged in
within that time, it was possible to reconnect with the old task, rather
than starting a new one. That could be nice for Grex, given all the
trouble I have with dropped connections.
Barring that, it seems like the easy way would be to kill the orphans
when the connection is lost, rather than having a kill orphans script.
But then I don't have to program it.
|
drew
|
|
response 43 of 59:
|
Apr 4 20:25 UTC 1999 |
That, I think, was the computer at Wastern Michigan university. The command
was "attach" instead of login; it prompted for a password, then you could pick
up where you left off.
|
davel
|
|
response 44 of 59:
|
Apr 4 22:32 UTC 1999 |
nohup (and the various underlying system features that make it possible) are
pretty basic to the operating system. To try to disable them so that orphans
are always killed right away might be pretty hard ... and I'm not sure it
would be desirable anyway.
|
prp
|
|
response 45 of 59:
|
Apr 5 02:14 UTC 1999 |
After thinking about this, I'm more confused. Are you telling me that
on a standard Unix system, when someone hangs up the phone rather than
logging out, the task just stays around until someone kills it by hand?
That cann't be right.
If I remember right, Grex has a fifteen minute timer which automatically
logs people off when there has been no input. How does that work?
|