It would be a pretty bad solution if there wasnt a way to ensure everything was read only. embperl was designed for embedding perl into html pages, im sure it can handle that type of permissions checking.

I doubt anyone is going to be able to drop in 'rm -rf /*' .

As I said, I'm a total n00b concerning Perl. Until today I only knew that it existed somewhere, hehe.
Mind you, I'm not trying to stir up shit here, just trying to help. "Perl worms" were the first thing that came into my mind after reading the previous posts, so I just wanted to mention it.

What exactly is the difference between Perl and embedded Perl (embperl)?

I looked around on perl.com and /perl.apache.org/embperl for a bit, but couldn't find an exact explanation of the differences.
Perl has lots of low level IO functions, embperl doesn't seem to have these. Is embperl just an addition to normal Perl featuring all functions of its "father"?

If so, it might be a good idea to block their use in EQEmu.

Yeah, security is always an issue. I imagine that embperl, should it catch on, will become slowly more refined, though. Since perl is a veteran of CGI, it already has powerful security features that could be applied (and currently aren't). If you want to enable Perl, but are highly concerned about security, I'd recommend enabling taint checking or disabling the #plugin interface, chroot'ing the process, and only using quests that you have written/converted yourself. Perl exposes a lot of power... that is precisely why I wanted to embed it.

[quote="Mongrel"]As I said, I'm a total n00b concerning Perl. Until today I only knew that it existed somewhere, hehe.
Mind you, I'm not trying to stir up shit here, just trying to help. "Perl worms" were the first thing that came into my mind after reading the previous posts, so I just wanted to mention it.
[quote]
Don't sweat it... it is a valid concern.

The only real difference is that embedded perl is embedded into another program in some way. You should be able to do everything (and then some) that a standalone perl script could do.

There isn't too much info on it. I am only aware of a handful of popular programs (2 irc clients, Apache, a few others) that have full-fledged native perl interfaces (as opposed to wsh interfaces).

No, this implementation can do everything that standalone perl can do.

I doubt it. At present (assuming the #peval interface is not avaliable), there is no way for an end-user to directly inject their code into perl. To be subject to most errors, you would have to have bad quest code. If you are really worried about security, you would have to review each quest. Otherwise, you are implicitly trusting the authors (just like with eqemu itself). The bottom-line is that in most cases a user would have to have already compromised you system with a priviledge escalation attack in order to abuse perl. To the person who can already do this, perl's avaliability is only a slignt convenience.

I'll try to not sound like an utter fool here, but here goes:

Wouldn't the parser have to be written in C or C++, since it would have to directly interface with the zone server interactively. (not like just loading something up once, b/c if you load all that in memory initially that would definately be a memory hog) Basically my thought came from that it would have to spawn and despawn mobs and such. And if when written in C or C++ (might be better languages initially, not too sure what all is out there that's cross-platform compat.), then be optimized in ASM.
Techincally, having each seperate quest in a text for is great, since it only has to access a small file for each quest, and then each text file identified with a mob is great as well.

Well, there was was babbling on in random thought, and I probably still came off like a fool, but if you have any comments to ease my curiosity, please feel free.

EDIT:
Side thought, what about writing it in a scripting language?

I have no idea what you're going on about. When you read your own post, what kind of responses do you think you might get from it?