Thanks for the reply. Point by Point:

...I'm wondering what all the hubbub is about.

During a chatterBox discussion the same day, merlyn very clearly mentioned security risks associated with the original design. (See Understanding Secure File Organization for a diagram.) This made me nervous, since I was trying to retrofit the sample to be more secure, a process I am still learning.

I originally thought, as you point out, that setting permissions was adequate. The warning, along with some of the follow-up commentary suggested that it wasn't. So, I searched PM for security and found several different discussions about various risks but fewer discussions concerning solutions.

Thus, I'm trying to collect ways to solve potential security risks, as well as write perl applications that are easier to maintain and move. (Thank you for noticing, BTW).

I have read the FAQ's, several books, and many, many links. Little appears to discuss architecture, that is, layout out an application with an eye for security.

One comment that stuck, though, was that one way to reduce the information that can be potentially exploited is to reduce the amount of information publicly available. My theory, then, is that by compartmentalizing code into specific "need to know" areas, I can reduce the number of visible holes.

I hope this isn't security through obscurity, as that appears to be a Bad Thing, along the lines of Cargo Cult Programming and other things to avoid. My request for wisdom is to make sure I'm on the right track.

...if you configure Apache correctly, the directories make no difference.

Would you mind expanding on this a bit? What are some things to look for? I presume it's more than:

• Avoiding symbolic links
• Ensuring IncludesNOEXEC is active for the httpd\ directory
• Making sure that ScriptAlias points to a directory *outside* of httpd\.
• Setting permissions of CGI scripts to 755.

Again, I'm trying to a) learn and b) start a discussion that documents the security practices of other Monks, especially the ones with the most experience (pun, intended).

...making more directories does not improve your security without obscuring it (permission bit mask confusion!)

Permission bit mask confusion?

...I'm a bit scared of your /lib directory. Are these modules or libraries specific to the app? Do you only use them in this app?

Again, just application libraries and personal toolkit libraries that aren't yet in a state to be shared. The toolkit stuff will (I hope) eventually get to the point where they're be shared across multiple applications, but until they're at that point, I confess I am duplicating a few functions here and there. By design It's a way for me to experiment with making what I think will be common routines, while buying me a little bit of time to a) make sure I'm not reinventing the wheel and b) making sure that they really should be toolkit routines.

...I notice that you are organizing well, but wonder why. Few programmers are truly gifted in the sense of organization and I'm sure that future program maintainers will thank you for the easy job of being able to know what's going on in your code.

In part because I have, over the course of my career, inherited too many poorly organized applications. I don't expect to spend my entire career with this employer, so I would like my stuff to be easily--and, perhaps more importantly--quickly understood by the poor sap who has to maintain my legacy code. Also, it's a sanity check for when *I* have to maintain the system in a few months/weeks/years/etc.

...just block it out with an Order deny,allow for everything except .html, .shtml, .cgi and anything else you are serving.

Hm. I hadn't thought of that. *ponder*

How does this strike you? Use (and allow) .cgi for the scripts called by the HTML forms, but use (and deny) .pl for the "kit" code. Is that an effective measure? Or have I forgotten something or inadvertently stumbled on another obscurity or cargo cult meme?

Hey, glad to be of help. My thoughts are pretty much entirely centered around making sure your Apache configuration is set2go FIRST before you get fuddy-duddy. What I mean by "permission set mask" is that it might get confusing- which users may have access to which directories, etc. If you don't want (nobody) to read the file, simply set it in Apache- it's much more readable and much more integrable (since you'll be grouping all of your security stuff into one convenient Apache .conf instead of some security measures here, some there...) Your directory structure, as I said, has little to do with "security" per se- all you really need to do is have a meaningful Apache configuration. Every directory can have its own .htaccess file as well as other configuration mechanisms. You can, of course, look more into this at the Apache FAQ. What I see here is too much time spent on something that may be effective but could have been simplified with a few lines in Apache .conf. By default, I believe, .pl is executed as CGI, so you might want to turn that off or consider renaming your itty-bitty perl libs to .lpl or something. You should definitely change your configuration to serve ONLY files that have a specific suffix- this is the base of webservice security. You may at some point want to throw in some documentation for the program, maybe in the form of a .txt or .doc. You certainly don't want that served out. So use LIMITs in the .conf liberally and your security is ALL set. Remember, it's most useful to the future programmers to look at a .conf rather than scrunge through a potentially large number of directories searching for a permission set. Apache.org has numerous examples of configurations, probably one already that fits your needs to the T. Order deny,allow is your friend and that should be seen multiple times in your .conf. It means, if it's not confirmed to be served- don't serve it. (period)

About your library routines: I obviously don't know enough to make an informed decision about your packages and their future usefulness, but I would still find a centrally located directory of packages infinitely more useful. If you are writing packages of non-reusable code, you're missing the point of OOP- REUSABLE CODE! Reusable code is infinitely more useful than a function-specific package. Even if you have to write a few more lines in the main function, you are saving yourself trouble later by making the package reusable by other layers of programming, especially in the debug phase which is the leech on programmers' brains...well, have fun!


AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.