Sorry, I deserved that, for being a bit flip in my answer... Didn't mean to imply obfuscation was an acceptable security practice...

What I was getting at was just this: The best I can do is set permissions for my script as 0700. For my script to be able to read the secondary file, the permissions on the secondary file most likely would be 0600 with the same owner as my script. So if that user account is compromised, anyone who can read my script can read the secondary file too. At that point I'm basically hosed, so I might as well do what I can and hope the cracker isn't a Perl hacker...

For the Apache server, I will definitely look into DBIx::Password as suggested by chromatic.

No. Wrong. See my discussion of setgid/setuid programs a few sections below.

You don't have to set your code to 0700 to make it secure. Make the data 0060 and make your setgid code do a thorough authentication before it reads the data file.

You don't have to worry about the group being compromised, because you don't even need to have any members in this group. No one can read the data except your program. If you build sufficent security into the program, you're all set.

(This time I remembered to log in...)

buckaduck

Please take no offense, but there is a bit of fault in your logic.

If someone has access to that one account, why don't they have access to root as well? Most likely they do. Especially if the machine is set up well, so that root is the only user that can get access to that account. At that point don't worry about the perl script or the files that you're working on. Worry about the machine (rm -rf /).

Hoping that the cracker isn't a particular type is about the worst security you can carry, since crackers come in more flavors than unix.

Hope This Helps,
jynx