Thor
I have to ask the obvious question:
. Why are you re-inventing the (perfectly god) wheel?
The filesystem is easy to manipulate from within SQL Stored
Procedures, or
directly from the app, with VB or WSH - or you're preferred
development
environment. We already know how to secure a filesystem and
it's credentials
database is already available to you as part of the OS.
Lastly, the
filesystem is much faster than SQL at returning file
objects, due to the way
in which they are stored.
It's quite likely that the only thing SQL can do
faster/better in your
scenario is return the "Select *" query faster
than the filesystem could
return a "DIR" command. Everything else will be
ponderous by comparison.
It strikes me that this may have something to do with why
WinFS hasn't made
it into Longhorn as databases simply aren't designed for
this type of data.
Hope this helps crystallise your thoughts.
Cheers
James
James D. Stallard, MIoD
Microsoft and Networks Infrastructure Technical Architect
Leafgrove Limited
Web: www.leafgrove.com
Email: j a m e s  l e a f g r o v e . c o m (remove the
spaces)
Mobile: +44 (0) 7979 49 8880
Skype: JamesDStallard
-----Original Message-----
From: listbouncesecurityfocus.com [mailto:listbouncesecurityfocus.com] On
Behalf Of Thor (Hammer of God)
Sent: 19 September 2006 19:35
To: Focus-MS
Subject: Storing Images in SQL Server (2005)
Greetings security professionals:
I'm starting a new development project where I'm
considering moving image
and document data into my database rather than storing the
files in the
server filesystem.
I've been mulling over the security implications of this,
and want to see
what others are doing in this area. The first thing that
comes to mind is
row-level security, and how others are handling the
"flow-through" from
table permissions to file system permissions where you're
creating the
resultant files. In my environment, I have directory
structures for
individual clients, with NTFS permissions applied to the
different client
directories so Client A can only see their own data, and not
Client B's.
I'm concerned that a possible breach could allow Client A
to see Client B's
data unless I impose row-level security on the DB or create
multiple views
for each client. I'm open to thoughts on how to best
manage that. Also,
are you guys "streaming" the content from DB
directly into the browser, or
are you creating a temporary file first, storing that in the
file system,
and then referencing that temp file? If so, how are you
handling
permissions on that? Via inherited directory permissions?
And what about
the context of the web user? You give them delete
permissions to "clean up"
the temporary files? The "steaming" context
seems a better way to do it...
Just seeing what issues those who have gone through the
deployment process
have run into.
Thx
T
------------------------------------------------------------
---------------
------------------------------------------------------------
---------------
------------------------------------------------------------
---------------
------------------------------------------------------------
---------------
|