Hello, This is my first post to the list. I'll try to get this right. The short version is that file attachments and other objects may be extracted from Notes databases regardless of any author or reader fields on the documents the objects are attached to. This goes back to the structure of Notes files. Most of the things people deal with in Notes are documents. Those documents have Note IDs. There's another class of stuff called objects. They are referenced by their Object ID. It turns out that both Note and Object IDs are really RRVs or Record Relocation Vectors. This puts each "thing" as a peer in the Notes world. Under most circumstances you don't ever have to be aware of Objects. If you use the published C API you can create, delete, read, and alter the objects in a database. Since an object is a peer to a note, any information a note has about an object will not be taken into consideration if the object is accessed directly. Consider this, when you detach a document you access it via the document. Any access to the attachment is mediated through the note since that's how you find the attachment. With this in mind, if you know the Object ID of a file attachment you can use the NSFDbReadObject call to load the file into memory. Since reader/author fields are a function of the note the object is attached to they aren't taken into consideration. I talked to Lotus this morning and they said it was not a problem unless I wanted to purchase a "Developer Support" contract. I already have a standard support contract but that isn't good enough. If I had a contract and could open a case with them *then* this might be a bug but not before then. Since this is supposed to be a "normal" thing to do, I figured I'd tell you all about it so you can keep it in mind when looking for problems. I tested this on a NT4SP6a and W2K workstation with a 5.0.6 server (NT 4 SP6a) using Notes 5.0.7. There is no particular reason this shouldn't affect any other 4.x or 5.x server since this uses the generic API. Can someone with access to Rnext verify if this works there also? To duplicate the problem: Create a new notes database Create a form with two fields. One should be rich text and the other a Readers field. Set the default value for the readers field to a role like '[Admin]'. Add the '[Admin]' role to the database and ensure you have that role. Create a document, attach a file in the rich text field. You should uncheck the 'Compress' box so you can still read the file after extraction. The extraction process will return the compressed file in the 'HUFFMAN 1' encoding. I don't know how to read that right now so this is best checked with uncompressed data. The problem works the same either way. I suppose if the field is encrypted you will get an encrypted file back - not much good without the key. Alter your access so you have reader privileges without the [Admin] role. You should not be able to locate the document in the database. If you can you haven't followed the directions correctly. Run the 'DumpObjects' code against the database and look for a larger object. That is your file attachment. You have successfully extracted a file attachment without having access to the document it is attached to. You'll also notice that your object access isn't tracked in the usage log. Try this under a different name to drive the point home. You will see a connect with zero documents read or written. See http://www.greentechnologist.org/domino/NSFDbReadObject.txt for information on the API call. See http://www.greentechnologist.org/domino/DumpObjects.lss for the object extraction code. The only workarounds or solutions I can think of involve either not using file, OLE, and ActiveX objects, encrypting documents by default or banning developer clients from untrusted users. If you ban developer clients also make sure to block lotus.com and notes.com from web access. Either that or just ignore the problem as unlikely to be exploited. Cheers, Joshua b. Jore Domino Developer (ex-candidate for mayor of Minneapolis) 651-704-7043
This archive was generated by hypermail 2b30 : Mon Sep 17 2001 - 13:10:50 PDT