Even if you have shares that don't expose other parts of the network that you don't want exposed, doesn't it seem risky to allow clients to write into the image folder? What if they do something wrong and overwrite an existing file? It just seems that the files are vulnerable.
Can you set up permissions so that you can add files, but not overwrite existing files? Thanks for you info... Kevin On 9/28/05, David Sommers <[EMAIL PROTECTED]> wrote: > [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 > ------------------------------------------------------- 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
