directory and file access for modules containing sensitive information

silent11 has asked for the wisdom of the Perl Monks concerning the following question:

I use the below module as a layer of security between my database accessing perl scripts and potential trouble makers. I'm sure there are better ways to implement this, however this is what I use.

My question is regarding the directory and file permissions of the module and the directory containing the module. What settings would be the most secure. This will be hosted on a shared UNIX hosting provider. Currently both file and directory are set at 755.

Thanks.

package DB;

use strict;
use DBI;

sub connect
{
my $db_name = "xxx";
my $host_name = "xxx";
my $user_name = "xxxxxx";
my $password = "xxxx";
my $dsn = "DBI:mysql:host=$host_name;database=$db_name";

return (DBI->connect ($dsn, $user_name, $password,
{ PrintError => 0, RaiseError => 1}));
}

1;
[download]

If there are safer means of accomplishing this ( removing user and pass info out of the script ) please mention them.

-silent11

Comment on directory and file access for modules containing sensitive information Download Code

Replies are listed 'Best First'.
Re: directory and file access for modules containing sensitive information by idsfa (Vicar) on Jul 28, 2004 at 16:07 UTC
I would strongly recommend decoupling the data (in this case your login info) from the code. Rather than hardcoding this in, have the module use values specified in a separate configuration file. See Config::Easy or a similar module for some examples. As for the location of the config file, it is definitely more maintainable to place it outside of the perl hierarchy. Consider what happens if another program wants to use your module for a different data source. Your greatest code re-use and ease of maintenance options will be to provide methods in the package which can accept either a filename or a hash of configuration options from the calling program. This abstracts the specific application (and application specific info like the database logins) from the module ... which is the whole point of writing a module. Oh yeah, and the permissions on the config file will depend on how the program is run. If only one user needs to run it, 400 is good. If you can restrict it to a single unix group, then 440. Updated with clarifying example skeletons of the methods: `sub readConfig { my $configfile = shift or die "No config file supplied"; # Read in the config file and set module-wide options # NB. I don't recommend "do" for this, as config files # shouldn't be able to contain executable code (IMHO) . . . } sub setConfig { my %opts = shift or die "No config options supplied"; # Set module-wide config based upon passed options . . . }` [download] If anyone needs me I'll be in the Angry Dome.	[reply] [d/l]
Re: directory and file access for modules containing sensitive information by bigmacbear (Monk) on Jul 28, 2004 at 15:49 UTC
Gee, I was just about to ask a very similar question. I will be most interested in what the other monks have to say. I will add that putting sensitive information within a module's source is a really, really bad idea. Any user of the system can run 'perldoc -m' and get the full source code of the module, in which case 'all your password are belong to us'. :-( My question is, would it be a good idea to put the sensitive information in a separate file in the directory alongside the module, use "do" to slurp it in, and restrict permissions accordingly -- or would it be safer to put that information somewhere outside the perl library tree entirely, such as /etc (or /usr/local/etc)? I would think putting these things outside the Perl library tree will wreak havoc on the build process, though.	[reply]