Yes, that seems like a good approach since it doesn't change existing behavior. In that case, the above line could actually be simplified to: ClosedFilePath=|C:\


Thanks, that's all anyone can ask.

By the way, I noticed that this behaves differently in the sandbox:

Just curious - is this related to your comment that some things happen before Sandboxie knows whether it's a file or folder?

Edit 2: Restored temporarily snipped text.

I don't know yet.. I'll check this while I'm working on the next beta version.

Version 3.51.09 adds support for the a single character wildcard match through the ? character in addition to the multi-character wildcard match through the * character.

Note that * matches zero or more characters, but ? matches exactly one character.

I also intended to add the option we discussed here, of prefixing a leading pipe character ( | ) to cancel the suffixing asterisk ( * ), but this will have to wait for the next version 3.51.10.

Tzuk, thanks so much for working on this - I know you have a lot of other things to do. In brief testing, the ? wildcard seems to work ok. But funny things happen when I use ?* to match one or more character, as required in wraithdu's original scenario.

Example 1: This completely blocks access to C:\test,

but my intention is to only block the contents of C:\test\AnySubfolder\.

Example 2: If I set ClosedFilePath=C:\??*.txt\ and run Explorer sandboxed, I immediately get:

This isn't a bug, but perhaps illustrates a couple gotchas. If the user intent is to block only folders in C:\ root, he may be surprised to find that the pattern matches not only files, but files that are all the way down in Sandboxie's program directory. Hopefully, the addition of the | wildcard will restrict the pattern to only match folders.

Thanks, I'll look into both problems you report here.

These problems should be fixed in version 3.51.10.



The way I fixed this is the Sandboxie installation folder is now always treated as a read-only folder, ignoring any XxxFilePath settings that may affect it. So ClosedFilePath=*.txt blocks access to all *.txt files, except those in the Sandboxie installation folder which will not be subject to this.

I think there were one or two cases when people somehow got a copy of SandboxieRpcSs into the sandbox, and this ended up being a problem when they upgraded their Sandboxie. So the read-only installation folder approach has benefits in this scenario as well.



I fixed this, it was a minor bug that caused a question mark immediately before an asterisk to be treated as "zero or one characters" instead of "exactly one character".



I also added handling for the | prefix in version 3.51.10:
Specifying OpenFilePath=C:\MYTEMP is the same as OpenFilePath=C:\MYTEMP*
However specifying OpenFilePath=|C:\MYTEMP means you don't want a suffixing asterisk wildcard.

Tzuk, ?, ?*, and | seem to be working great - I retried the above 2 examples, as well as wraithdu's scenario and some others. Thanks for gifting us this increased flexibility.


Yes, this sounds like a good idea. This also happens to prevent problems where, in the past, something equivalent to ClosedFilePath=MyPortableApp.exe,%ProgramFiles% would completely prevent MyPortableApp.exe from running (since all sandboxed processes apparently require access to the Sandboxie installation folder).

I wonder if I can get a tip on what I am doing wrong with using this:
(Also, I encountered a serious problem as described below)Example:
"MyTemp" folder containing a .txt file and cascading sub-folders, each with a .txt file:Using Direct Access to specify the 'C:\MyTemp' folder:
OpenFilePath=C:\MyTemp\
As expected, 'MyTemp' and all sub-folders have Direct Access for a sandboxed Notepad.

After revising the line by adding a '|' at the beginning:
OpenFilePath=|C:\MyTemp\
and also by editing out the trailing '\':
OpenFilePath=|C:\MyTemp

Now neither the 'MyTemp' folder and its .txt file, or any of the sub-folders and their files, have Direct Access.
Revising and saving any of the .txt files results in them being stored in the sandbox.
Creating a new .txt file with sandboxed Notepad will save it in the sandbox, and not outside.

I expected to still have Direct File Access to the 'MyTemp' folder, but I guess I'm not understanding something.
----
I encountered a serious problem when using the above.
With this line:
OpenFilePath=|C:\MyTemp\
or with
OpenFilePath=|C:\MyTemp

When I use a sandboxed Windows Explorer to rename the MyTemp folder (to MyTemp2), the MyTemp folder outside of the sandbox is deleted.

One time, the MyTemp folder was recreated inside of the sandbox, along with the MyTemp2 folder.
In further tests though, the MyTemp folder was not recreated in the sandbox, and a hidden 'C' folder with a MyTemp2 sub-folder, and its sub-folders and files, was created in the sandbox.

3.51.11

I think what you have to understand is that

OFP=|C:\MYTEMP

matches EXACTLY that path. It does not match subfolders or files within that directory. So you could create this path in the real system, but you would not be able to create anything within it (not a very useful idea). Also, it would match if you tried to save a text file with Notepad with the name 'C:\MYTEMP' without the .txt extension.

If you try to create anything inside that folder it will be sandboxed, which will cause a sandboxed version of C:\MYTEMP to be created to hold the new file/folder.

Your rename operation makes sense, since renaming is basically moving a file/folder. The system has access to C:\MYTEMP so it can move it. But you renamed it to a path that is not allowed access and must be sandboxed. So you moved the accessible path into the sandbox essentially.

All interesting tests, and in my eyes prove the changes tzuk has made work as expected.

Thanks for your explanation, wraithdu.
Your reasoning for the folder deletion outside of the sandbox makes sense to me.
I certainly didn't expect it, though.

I know it's clear to you now, but in case anyone else is wondering - to have direct access to MyTemp but not its subfolders, two settings are required:

The above OpenFilePath has an implied * suffix, and because the * wildcard matches backslashes, it can't be used to specify a specific level in the folder heirarchy. Thus, an accompanying ReadFilePath or ClosedFilePath is required (which, unfortunately, may not suit everyone's needs).

-----


I agree with wraithdu that this is correct (assuming that the contents of MyTemp didn't vanish into the ether)...


Hopefully, the sandboxed MyTemp contained the contents of the original MyTemp folder.


Hmm, the hidden 'C' folder sounds a little funky.

(Clear? I'm getting a headache already)
I'll have to think about the '\?*\?*' part.
Are there 2 parts to this, because I specified 2 sub-folders?

P.S. What happened to the "|" character, in the above?
Is it:
OpenFilePath=|C:\MyTemp\
ReadFilePath=C:\MyTemp\?*\?*

Intuitively, we might think that subfolders of MyTemp could be specified by: ReadFilePath=C:\MyTemp\?*\

But because of the way Sandboxie checks paths - C:\MyTemp\file.txt, for example, is also checked with a backslash suffix, as C:\MyTemp\file.txt\ - files end up matching the above ReadFilePath, along with folders. (More detail in tzuk's explanation.)

So since we can't directly specify "subfolders, but not files," we use a workaround - we specify the contents of the subfolders rather than the subfolders themselves. That's how we get the second "?*" wildcard.

In summary, C:\MyTemp\?*\?* is saying: C:\MyTemp\AnySubfolder\AnyContent


Actually, we don't want the "|" operator here because it will only match C:\MyTemp\ exactly. That means C:\MyTemp\file.txt won't match, and won't be OpenFilePath.

A couple general tips/thoughts...

1. As previously discussed, something like ClosedFilePath=*\test\ will block both files and folders named 'test'. When using ClosedFilePath=*\test\?* to block only folders (not files) named 'test', be aware that programs can still list 'test' folder contents.

2. Adding ClosedFilePaths for all sensitive data can be impractical. However, the '|' operator might help by sort of limiting access to programs that already know where to look. For example:

Here, a program blindly searching D: will get Access Denied when trying to enumerate files and folders in D: root. However, a program which knows (or is told by the user) where to find specific files/folders can still access the data it needs in D:\SubfolderWithUncommonName.

There are caveats, though. In a sandboxed Explorer, I was able to read and modify files in subfolders of D:, but not move or create anything (despite my 'Full Control' NTFS permissions, including traversal). Also, in a sandboxed command prompt, I was unable to cd or dir any D: paths.

I suppose these attempts to gain a little security through obscurity could be undermined if smart malware checked the search index, Recent Places, registry, etc.; but if it really matters, a few more ClosedFilePaths and ClosedKeyPaths ought to mitigate this risk.