'Protecting' Perl Code?

An anonymous reader asks: "Ok, so here is the scenario: my company has some software that is used internally and it is written in Perl. We now need to put this code on a server that has 'public' access (it's a university machine). We provide root access to the system for the purpose of learning, but we need to keep the code from being viewed or edited. Is there anything to do besides the 'perl2exe' and the ActiveState compiler? How effective are those really at protecting code?"

Comments

Goes against the machine's purpose

[klui]

If it's for learning and people have root, why put it on this server if you don't want people to learn from it?? Still want to do it? Move this perl code to another box and call it via RPC.

Not Possible, Permissions, Jails/Sandboxes, Others

[MBCook]

My first though was it isn't possible. After all, it's root. Root is supposed to be able to do anything.

My second though was permissions. Why do the students need root access? Couldn't you make some new account that had permissions to do anything but access that one directory?

My last thought is a sandbox (or I think the BSD concept of a Jail is the same idea). If you were to run Linux on Linux (Xen, or just some other sandbox, maybe even chroot) then you could give them root, while keeping them out of the true root.

It's a tough situation. Does it really have to be on that server? You can't stick it on a new server your company buys for the purpose and donates (what is more important, My last idea (a bit extreme, I would think) would be to modify the Perl interpreter to run the perl code through a decryption algorithm first (so the source on disk would be encrypted so it couldn't be read). With open source software, there is no reason this isn't possible (would hurt performance though).

Does Perl support some kind of tolkenizing? When you run a Python script you get the .pyo (I think) file that is basically the cached compiled Python byte code. Can you do that with Perl? It isn't perfect (can be disassembled back into Perl, but without variable names, etc) but it is better than plain text.