|
Grex > Coop11 > #51: Enabling CGI scripts for Grex users | |
|
| Author |
Message |
| 25 new of 59 responses total. |
remmers
|
|
response 16 of 59:
| 
Dec 7 00:24 UTC 1998 |
I knew that "nobody" is just a particular "somebody", but hadn't
thought through all the implications of that. One could at least
preventing game-playing with the system CGI's by having user
CGI's run as another anonymous somebody, say "nobody2", but
then people could still work mischief on other users, which is
probably nearly as bad.
|
remmers
|
|
response 17 of 59:
|
Dec 7 00:28 UTC 1998 |
Misti slipped in with #15. That would control some potential problems,
but I'm afraid the administrative overhead would be excessive. I
know what it's like to read through gobs of source code written by
other people. I wouldn't relish being cgiadm.
|
albaugh
|
|
response 18 of 59:
|
Dec 7 02:15 UTC 1998 |
Is it possible for the web server to "deny" cgi submits from sites other than
its own? If so, that would prevent people from writing grex-hosted hit
counters and offering them to "the world".
|
hhsrat
|
|
response 19 of 59:
|
Dec 7 02:21 UTC 1998 |
Couldn't you offer CGI the same way you offer outbound telnet? Paying members
have access to it, and non-paying persons don't. That would drastically reduce
the number of people who have access to it, thus making it much easier to
police.
|
mta
|
|
response 20 of 59:
|
Dec 7 03:52 UTC 1998 |
That might be tricky if someone wrote a CGI script, sent in membership for
three months and then let their membership lapse. Someone or something would
have to track down all CGI scripts and verify that they were accessible only
by members.
|
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.
|