[Nancy/Kevin/Others - been off the net a bit this last week, I'll get to
my backlog in the next couple days but I saw this message...]
Kevin, I don't know what security is in place for client to server file
writes (or client-side reads) so I can't give a firm answer on what
VistA Imaging is doing... but I can tell you how other Windows
developers do it.
There are many solutions and file path access is not a limitation of
Windows, just the developer's implementation of "security". Windows has
two sets of permissions when dealing with shares, the share permissions
and the underlying folder/file permissions. First and foremost, share
permissions trump file ACL (access control lists). So if the share says
RO (read only), even if you're an admin with full control - you can't
write to the share.
As a developer of this particular situation, I have at least 3 options.
1) Control the ACL. Accessing and manipulating the file system is just
part of Windows, as it is with linux. It's not hard to restrict a
folder and/or file to any ACL for any SID (user/group identification).
The tricky part is making sure you treat it like multithreading - you
need to handle deadlocks, race conditions, and priority failures.
Deadlocks *as in* you're sitting around waiting for something
that doesn't happen.
Race conditions and priority failure *as in* reading before the
writing is done.
2) Control the stream. Similar to the symlink in linux, you can do ntfs
streams and virtual file writes depending on the platform you use. For
.NET, the easiest is to handle a file submission using a web service and
handle everything behind the scenes. Take in the parameters including
the file, return back a "virtual location" to access it in the future,
etc.
3) Drop box. This is what we do in iMedConsent at the VA. Our
documents are encrypted and each is accompanied with an encrypted XML
file. The XML file includes all the meta-data and the document is read
in with it. It's a WO (write only) folder so once you put it in there;
it's pretty much taken immediately. [We have a Windows Server on an
NTFS file watch so it does literally grab it once the file system
records it, there's no stupid polling or looping involved].
And of course you can take several variations of the above and get
creative beyond that. Kevin, your RPC method fits well into #2.
As for the VA, don't quote me here, but I believe they're using option
#1 "sorta" by impersonating an NT user and using that user's credentials
to access the share/file. That way an "ordinary" user couldn't browse
the SMB shares and do as they please.
And as Greg pointed out, E:\images\patientX\ could easily be
\\server\imageShare\patientX\
If you have IIS running, you'll note IIS also support virtual
directories. You don't have to have you files in C:\inetpub\wwwroot\,
but instead can have vdir links to other drivers (or even network
shares) for serving up web resources.
/David.
David Sommers, Architect | Dialog Medical
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kevin
Toppenberg
Sent: Tuesday, September 27, 2005 6:08 PM
To: Hardhats Sourceforge
Subject: [Hardhats-members] VistA Imaging and file paths...
This is a bit complicated, but hang with me here.
BACKGROUND INFO
-----------------------------
When you call RPC call: MAGGADDIMAGE, it looks in:
IMAGING SITE PARAMETERS file (2006.1),
field .03 (IMAGE NETWORK WRITE LOCATION), -->
--> [ptr to NETWORK LOCATION (#2005.2).
field 1 (PHYSICAL REFERENCE)
This PHYSICAL REFERENCE field is supposed to name the physical
location of the site to be written to. e.g.
"\\ISWIMG01\SOMEDIR\MAGE1\".
The MAGGADDIMAGE call, then uses this path to add to the image that
should be uploaded. e.g.:
\\ISWIMG01\SOMEDIR\MAGE1\ZZ000001.JPG
This full filename with path is then passed back to the windows
client, and the client then saves the file to this path.
COMMENT
---------------
This seems like a risky way to do things. By giving the client access
to the full path, it would give them opportunity to try other paths.
It would be up to the server to then make sure it somehow security
enabled on parent directories. I.e.:
\\ISWIMG01\ <--- must be locked
\\ISWIMG01\SOMEDIR\ <--- must be locked
\\ISWIMG01\SOMEDIR\MAGE1\ZZ000001.JPG <--- unlocked.
I'm guessing windows allows this, but I don't know how to. And I
wouldn't want to risk that I had missed some directory somewhere that
was left unlocked. Then also I would have to consider that this would
be server code that was trying to access the directories, and
sometimes other server code would have a legitimate reason to accesss
those directories. Best to avoid the issue I think.
It seems that using the Apache way of setting things up would be
better. I.e. there is a specified directory on the server that is
used as the root of the users request. I.e.
Actual User
Server Request
Path Path
-------- ---------------
/var/local/www/ /
/var/local/www/sub1/ /sub1
As I posted earlier, I have been perfecting binary file transfers via
a RPC Broker so that an Imaging Client does not have to be privy to
the image server's filesystem. On my server code, I currently I
prefix all requests with a path that puts requests into a sub
directory. Thus:
/M/001/101/IMAGE1.JPG
would become something like this
/var/local/imageserver/M/001/101/IMAGE1.JPG
I have this offset directory hard coded in currently, but It would be
better if it was stored as a setup value in a parameter file
somewhere. This leads me to my questions.
1. Is my thinking off here?
2. If I add a field to file IMAGING SITE PARAMETERS file (2006.1),
using my numberspace, would that be a bad thing if I wanted others to
use it someday?
3. If I add a field, can such a field be put into a KIDS file, such
that after applying the patch, that other users would also now have
that added field?
4. Would the proper thing to do, instead, would be to create a
separate file just for this parameter?
Thanks
Kevin
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads,
discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
