Allowing Apache to Write to filesystem

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

Its not so much a concern here in my development sandbox, but as I think about how my script will be deployed, perhaps in shared hosting environments, I shudder to think of the security consequences.

Part of what I need this script to do is:

accept user input,

process input,

create and post a pdf in a web accessible directory

hand pdf off to hylafax for distribution

This started out as a working cli script, and on the road to being web-available as a cgi script, I'm having to jump over these privilege issues. Surely someone here has done this sort of thing before.

How can I safely allow a script running as the apache user to write to a web-accessible directory, without exposing that directory to tampering in a shared-hosting environment, where others can also write into the webserver's document root or deploy scripts that can?

-- Hugh

Comment on Allowing Apache to Write to filesystem

Replies are listed 'Best First'.
Re: Allowing Apache to Write to filesystem by chromatic (Archbishop) on Feb 24, 2006 at 06:13 UTC
If you modify your script to write to a database instead of flatfiles and then create your PDF from a separate process, you can avoid some of the potential security holes.	[reply]
Re^2: Allowing Apache to Write to filesystem by hesco (Deacon) on Feb 24, 2006 at 08:15 UTC
I had thought of feeding this data into a db backend, but after consulting with our host decided it made more sense to cache this static content, ready to be served by apache without further processing overhead. I'm assuming that handling the pdf creation in distinct processes would mean using either eval or exec? I'm not quite sure how that will help. One friend I consulted today on this suggested using an suid wrapper or a sudoers entry to permit apache to handle writing to a directory it would otherwise be unable to write from. My friend also suggested adding host based authentication to my existing userID -> password challenge response as an added precaution. I'm still rereading the sudoers man page after a two year hiatus from using it. -- Hugh	[reply]
Re: Allowing Apache to Write to filesystem by jonadab (Parson) on Feb 24, 2006 at 13:33 UTC
My approach would be to allow Apache to write to a certain directory somewhere, preferably one that is not directly served to the web, and then have another process running as another user watch for new files there, check that they meet certain criteria, and then take some desired series of actions with them, such as copying them into a certain web-served directory. The more restrictive the 'certain criteria' can be, the more you reduce the potential for abuse. At minimum I would definitely restrict it to files ending with certain extensions, such as '.pdf' and any other specific extensions you really need. Ideally, if performance is not prohibitive, I'd prefer to also check that the files are actually valid PDF files. Additional checks could be made as well, e.g., against the filenames. Sanity? Oh, yeah, I've got all kinds of sanity. In fact, I've developed whole new kinds of sanity. Why, I've got so much sanity it's driving me crazy.	[reply]
Re: Allowing Apache to Write to filesystem by idsfa (Vicar) on Feb 24, 2006 at 16:33 UTC
Your concern appears to be about ensuring the data integrity. You want to provide only the unmodified files that your process creates. I suggest that your PDF creator store a checksum/hash of the created files in a database, and that your download CGI only offers those files whose checksum is in the database. Before beginning the download, it can check to see that the file has not been altered, and throw an error if there is not a match. Digest::SHA (128-bit or better) would be a good method. Alternately, you could have your tool provide an automatically generated signature for each "official" file. GnuPG::Signature or the like would take you down that road. Updated: or better yet, Roll your DSA signatures The intelligent reader will judge for himself. Without examining the facts fully and fairly, there is no way of knowing whether vox populi is really vox dei, or merely vox asinorum. — Cyrus H. Gordon	[reply]