I have ClosedFilePath=D:\Desktop\SecureFolder\ under [GlobalSettings] Setting OpenFilePath=D:\Desktop\SecureFolder\ or ClosedFilePathDisabled=D:\Desktop\SecureFolder\ to a specific box does not work I need precedence on certain cases...
I asked a similar question recently here; I haven't replied yet as for my use case I can live with what it allows so I don't want to ask for additional development, but it's more limited that I initially thought. Firstly, are you in a security hardened sandbox, or do you have 'Prioritize rules based on their Specificity ...' ticked under Resource Access > Access Policies? These are supporter exclusive features I believe. It's my understanding (from the aforementioned post) that 'process match level' doesn't really do anything as it only operates on the same Property i.e. "OpenFilePath=notepad.exe,D:\downloads" can only override another OpenFilePath rule...which I think means it doesn't override anything. So you're left with rule specificity (the length of the match), which in your case should work if you change your definitions to: Code: ClosedFilePath=D:\Desktop\SecureFolder OpenFilePath=D:\Desktop\SecureFolder\ Basically, the OpenFilePath is a better match because it also matches the \ (more characters matching than the ClosedFilePath). It's a little awkward, but it works. The only exception to this is that it doesn't work at the root level for some reason e.g. D:\
The reason is that DOS paths like C:\ or C: are not used instead they are translated to NT paths like \Device\HarddiskVolume4\ and to open it you need the \ at the end so \Device\HarddiskVolume4\ is C:\ as directory while \Device\HarddiskVolume4 is the volume as a block device i.e. you can write to any offset on the partition. So internally C:\ and C: evaluate to the same path which is subsequently used. You could however use NT paths in the rules and then the specificity should work.
If I don't add the final \ to the global ClosedFilePath then the volume is open. If I add the final \ then it's closed but we're back to the same problem as before. My use case is that I just want to be able to open and modify a single file nested below the root, so whilst I currently can't browse to it I can type the full path, so it's not a major problem. I was hoping to be able to: Global ClosedFilePath=E:\ Local WriteFilePath=E:\ OpenFilePath=E:\documents\..\..\somefile.txt With the WriteFilePath giving me the ability to traverse the directories without giving read access to the folders contents. This partially works with non root folders until I get to somefile.txt as it's presented as a folder and if I try and open it I get the message "The directory name is invalid".
Yes I am in it and such policy checkbox is ticked. I have a certificate, yes. This worked out Code: ClosedFilePath=D:\Desktop\SecureFolder OpenFilePath=D:\Desktop\SecureFolder\ Thank you.
Slightly OT maybe. @Mr.X : Your first post has the setting "ClosedFilePathDisabled" which I have not seen before. Care to share a link to its description and usage? Or, perhaps @DavidXanatos can enlighten us
It does not exist. It is a n00bish intent to fix my issue, that's it. I'm not well acquainted with all Access Policies and syntax, etc.
If you define a ClosedFilePath rule in the Resource Access tab, and then uncheck it (on the left), it's stored in the ini as ClosedFilePathDisabled. I guess it's a way to keep the definition without it being in effect.
Thanks! I was not aware of this at all (n00b that I am). I tried creating a ReadFilePath and then unchecking it. It indeed shows as ReadFileDisabled in sandboxie.ini
Yes its just a dummy to lot loose it, the cor components are obliviosue to any ...Disabled entries they have no function
this is a * disastrous mess, to me. Edit: I am laughing at me and my poor IQ to understand quickly and timely. I am not mocking or despising @DavidXanatos work whatsoever. I let this clear cause I don't want this comment to be censored.
