• Why is it bad to hide the source?
• perldoc -q 'hide the source

Edit by castaway - Amened links to work better with PM

You could go suid, chmod 4111, but that is ALL to dangerous.
Well you cannot execute a script on either FreeBSD or Linux that has the SUID bit set ..

OK, you still end up with an SUID program, but what about putting the real Perl script in a directory that users cannot read, then calling it with this wrapper:

/*  wrapper.c  */

#define REAL_PATH "/usr/local/bin/secret/secret.pl"
      main(ac, av)
          char **av;
          
      {
          execv(REAL_PATH, av);
      }
[download]


Compile it:  cc -o secret wrapper.c

Put the real script in the unreadable directory:

# mkdir /usr/local/bin/secret
# cp secret.pl /usr/local/bin/secret/
# chmod -R 0711 /usr/local/bin/secret/
[download]


Make the wrapper you just compiled SUID root:

# chown root:root secret
# chmod 4711 secret
[download]


A unprivileged user should be able to execute the "secret" program, but not read the real Perl code.. so how dangerous would it be to have this suid program around? Maybe in the Perl script you could make sure no arguments are passed in as a first level precaution.. ? I know, it's a Bad Thing.

You could also just compile the perl script into an executable with perlcc - I don't believe you can see the source code.

you don't have to use the big gun (root user) to hide the script from 'normal' users. just create an extra user (with no extra privileges) and chown/chmod the directory/script to him.

~/runnables> su
Password:
tmodel# uname
FreeBSD
tmodel# chown root:wheel test.pl
tmodel# chmod 4711 test.pl
tmodel# exit
exit
~/runnables> more test.pl
test.pl: Permission denied
~/runnables> ./test.pl
At 6:00 AM, Seatac Airport, WA conditions were cloudy skies at  52&deg
+;F,wind was east at 5 mph.  The relative humidity was  97%, and barom
+etric pressure was falling from 30.05 in.
[download]

But using Access Control is safest.

chmod =r yourcode.pl       OR
chmod 444 yourcode.pl      OR
chmod a-wx,a+r yourcode.pl
[download]

AFAIK you can't execute a non-readable program on UNIX. Try it:

$ ls -la a.out
---x--x--x  1 joost joost 30 Jan 21 11:26 a.out
$ ./a.out
bash: ./a.out: Permission denied
[download]

"What should it profit a man, if he should win a flame war, yet lose his cool?"

That works fine on OpenBSD. Even a perl script, like this: ---x--x--x 1 root wheel 33 Jan 21 10:13 hello.pl can be executed by non-root user. But it has to be called directly, like: ./hello.pl Trying to run it with "perl hello.pl" will give permission denied... Advanced users will still be able to access the source with ktrace or ptrace though. But if you own the server, you could always hack your kernel to not allow tracing root-owned programs. And the users won't be able to copy your program to run elsewhere since the perms don't allow it...

I have a quick implementation of a hash/bang/bang (hbb) script invocation system using this mechanism. The idea of this was that:

#!! perl 
...
[download]

If you fiddle with permissions and this mechanism I'm sure you could do what you want. This would be in C.

The binfmt_misc stuff is very clean and simple to handle. You may have hbb to give you a kickstart.

Be well,
rir

Yes, here's a simple way.

Give no rights to the script source to the world, only to root. Create a C program that is setuid root, and execs perl with the script as an argument. Finally, make the script start by throwing away its root privilages.

Update: you need root so that the script can throw away its setuidity completely.

Hello Gorby.

I'm sure you have some legitimate reason to hide the Perl code from your users.

If I were in your shoes, I'd use Acme::Bleach.

This is a fun (ie, presumably half-joking) way to make your script invisible. I suppose a real Perl guru could still find a way to un-bleach it, but that might be hard.

Here's how it works:

frost@penitente% cat foo.pl
#!/usr/bin/perl

use strict;
use Acme::Bleach; 

print "Eyes only, sucka!\n";

frost@penitente% ./foo.pl
frost@penitente% perl foo.pl
Eyes only, sucka!
frost@penitente% cat foo.pl
use Acme::Bleach;

 ... many lines of whitespace here ... 

frost@penitente%

You have to re-add #!/usr/bin/perl on the first line (above use Acme::Bleach;) if you want to execute it directly.

You also want very much to keep a backup copy of the code somewhere safe, and be sure to not use Acme::Bleach in that copy.

This may not be as practical as some of the other suggestions, but it is likely to be more fun.

I suppose a real Perl guru could still find a way to un-bleach it, but that might be hard.

The code to 'un-bleach' is right in the ACME::Bleach module. It has to be, since perl understands Perl, not Bleach.

--Solo

--
You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.

Unfortunately sperl needless checks to see if the script really is either suid or sgid and complains if it is not. Gee I hate over-validation.

You can work-round this by making the script sgid to some innocuous group.

When you are using shared CGI hosting and use a database, you need to put your password in the program code or in a file that is readable by the process. If the server does not use suexec or a similar mechanism, you are in trouble unless you can find a way of allowing execution without reading, which is exactly what the OP is asking.

I'm glad to hear that BSD has that feature, but from what I've seen, Linux doesn't. You can add a wrapper (which is what suexec does), but you have to be really careful to ensure that it is done securely.