Hi Kim, > Are you saying there are configurations in which > %PROGRAMFILES% isn't even read-only, but execute-only?
Yep. Of course, very secure systems like that probably wouldn't have DQSD installed, either. But the point was really that if we're going to be doing it - why half-way? Let's just provide the most secure/compliant install possible so the users are not prevented from using SQSD becasue their system security has been tightened. > prefs/writable files %APPDATA% R/W +1 > localsearches %APPDATA% R/W +1 > executable/scripts %PROGRAMFILES% R/E > searches %PROGRAMFILES% R/E IMO: Executeables - program files Scripts/searches - "all users"\appdata Generally, the scripts will not be called directly, but read into a temporary file during the processing of the search.htm file. That file probably needs to be in the programfiles directory, but shouldn't need read privs to execute. The DQSD handler can invoke it directly as it does now and the htm file will just parse the appdata stuff based on the values returned from the loader object. > Does removing read access [to program files] and running > Office work? I don't know. On the servers I've removed read access from ProgramFiles I've never needed to install office. I *do* have DQSD installed on one of them, which I had to set full perms on the folder in order for it to run. Regards, Shawn K. Hall http://ReliableAnswers.com/ '// ======================================================== "Bad laws are the worst sort of tyranny." -- Edmund Burke ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ DQSD-Devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dqsd-devel
