Inline:
Relational Integrity comes for free with any relational database system
worthy of the name. You know that the BLOB is going to be there if there is
a foreign key constraint to other data in your database. If you use a string
"pointer" to the file system, you have no assurance that the file will
exist. This is not usually a problem until a couple of years down the road
when the original developers are long gone and someone needs to move,
migrate or upgrade the application or the underlying OS. Then all the files
go missing. If you want to move the app to another server OS, you could be
in more trouble because the file path embeds platform-specific notions about
file-separator character, PATH_MAX and valid characters in paths and
filenames that are platform-specific.
Transactional Integrity comes for free with the database. A file is inserted
or it isn't. You can't have a part of a byte stream written to a file
buffer. Since you have a primary key in every table that holds your BLOBs,
you don't have to worry about whether any file might be overwritten by the
next upload.
While not a huge security bonus, I have to say, this is the other major
benefit I see... As it is now, even with what I'm sure is a comparatively
small amount of content generation at my company, I see a very high number
of "orphaned" files that end up living on the file-system forever. Files
and images copied here and there, project ID's being renamed, but the "old"
files and directory structures persisting, and the overall issue with
synchronizing directory structures within this model. I did look at DFS,
but that's a solution to a different problem- one of distributing files
around within an infrastructure, mainly for high availability for users
within an already-existing trust and authentication infrastructure.
Replication is FAR easier to secure and control as far as getting the images
from point A to point B. We can do what we want with them from there.
Finally, the database acts as a sandbox between your application and the
underlying OS. It's pretty inconceivable that a malicious file inserted into
your database could somehow be executed by your underlying OS in the
ordinary course of things. Your clients could be affected but not the
server. If you're using .NET as your client database client, you also have
the option of code-access security to limit the I/O of your app so that it
can't possibly write to the server outside of the database:
//Permit read environmental variables PATH and PFPRO_CERT_PATH and nothing
else
[assembly: EnvironmentPermission(SecurityAction.RequestMinimum, Read =
"PATH;PFPRO_CERT_PATH;")]
//Permit read HKLM\Software\Microsoft\.NETFramework registry keys and
nothing else
[assembly: RegistryPermission(SecurityAction.RequestMinimum, Read =
"HKEY_LOCAL_MACHINE\\Software\\Microsoft\\.NETFramework;")]
//Permit read assemblies from the GAC and no other file IO
[assembly: FileIOPermission(SecurityAction.RequestMinimum, Read =
"C:\\WINDOWS\\assembly;")]
Thank you for this-- I was not aware of the fact this option existed... Big
bonus. ;)
I think I've got enough info to at least get started. I'm going to forge
ahead with my development plan, and see for myself what "real" issues are
created. This should be fun ;)
t
t
---------------------------------------------------------------------------
---------------------------------------------------------------------------
