On Thursday, Nov 27, 2003, at 01:26 US/Pacific, Tom Kinzer wrote:
Not sure, I'm not an admin by trade, but I was actually referring to the fact that some admins assume that user Perl processes that don't die, are doing so unintentionally.
Ah! an interesting take. Having been one of those folks who, uh, SCREAMED at the head of engineering
"I'll put that in the inetd.conf
when YOU can show me that it is not going to
just loop all out of control!"I can empathise with our hypothetical sys-admin.
But as a 'design pattern' I think ever good Perler needs to be asking themselves when IS it time to cross over and get into making 'daemons' because the type of problem is 'daemonic'(???) by nature.
cf <http://www.wetware.com/drieux/pbl/Sys/daemon1.txt> and/or check out perldoc Proc::Daemon for some basic ideas on doing Daemonology in Perl. <http://search.cpan.org/~ehood/Proc-Daemon-0.03/Daemon.pm> { pay attention to the Credits section, get the books, get in touch with the knowledge. }
It also helps coders get a better feel for the whole of the problem/process if they take the time out and have their 'own development box' - something that is getting easier and easier - one can slap together a fully tricked out linux box for less and less money. This way the coder also grows a sense of respect for their sys_admin and what they have to go through.
Which will help when one needs to talk with them.
{ and would prefer not to get their HEAD BITTEN OFF!!!
sysAdmins can be overly stressed persons, and will
attack if cornered. Be NICE to them. Note to
persons who are their own sysadmin: hold a
staff meeting, do not bite your own head off! You
may need it some day...}I'm sure there may also be security issues with the user/socket coding as well.
Hum... I wonder what 'perldoc perlsec' has to share on this point, he noted, uh, politely... { cf 'perldoc -q taint', etc, etc, etc.... have I mentioned today 'perldoc can be your friend.' 8-)}
What you will learn along the way is that good defensive coding practices will prevent most of the 'security issues'. Along that route one finds when, and where, one needs to just feel at home with using 'sysread' et al.
So while yes there are 'security issues' that come with doing 'socket level coding' - in that one opens one more means by which 'hackers could attack'. There are several ways to deal with that - not the least of which is go with a 'header/payload' approach in which one requires an 'id' indicating that this is an 'HTTP 1.1' or what ever protocol, and also the length of the buffer of the payload. This way the hackers have to KNOW which protocol they are going to 'attack' with - no protocol ID and one simply disconnects the socket connection.
But that way of course leads us into Protocol Design, and the more tedius and annoying stuff about implementing same...
ciao drieux
---
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
