Win7 Ultimate x64
SB Beta 3.49.10

So I think this is a bug, unless my logic is wrong. What I was trying to do was allow OpenFilePath access to a folder, but block access to subfolders with ClosedFilePath. I think the following wildcards should do it, but it blocks access to the entire folder instead.

My thinking is that in the CFP statement the additional \ should require that a matching file/folder be in a subfolder of Downloads. For example

would be allowed since it does not have the additional \ in the path, while

would be blocked since it has the additional \

In the current implementation, all access under Downloads is blocked.

Huh, heres what I did.
On my desktop, I created a file named "Dir1" (equivilant of "Downloads") and inside that folder is "Dir2" (a subfolder) and a folder "Dir3" inside that folder.
After setting up my sandbox, the way you had yours set up, my ini file now had these 2 lines:


I fired up good old Notepad in that sandbox, typed random junk, and selected Dir2 as the save directory, it failed with a "No permissions to access folder" message, which is to be expected. However when I tried saving the txt file to Dir1, it also failed with the same message.
So I guess you could say this has been reproduced.

The thing is though, I am trying to figure out why this happens...
I know that ClosedFilePath takes precedence...


But as per our settings, the only thing that should be blocked off are subfolders in Downloads/Dir1 (such as Dir2) and subfolders inside that folder (Dir3)...
Now I'm confused. Is it a bug in Sandboxie, or in our brains?

I tested originally with cmd.exe, trying to access and create files and directories.

I've also just tested a single OpenFilePath setting

I would expect only subfolders under zzz to be opened, but indeed writes are allowed directly under zzz. I suppose that a star meaning '0 or more characters' could expand to, for example

The question then is, how does Sandboxie (or Windows?) interpret that path? Is there a wildcard specification in Windows to mean '1 or more characters'?

This seems to be a very specific bug. With the following directory structure and setting

writes are NOT allowed to C:\zzz\dir1\, meaning C:\zzz\\dir1\ is NOT interpreted as a valid open path. To double check, this setting

correctly allows writes under dir2. So the problem clearly lies in how a \*\* path segment is interpreted.

I just tried both tests you've posted since my last post and was able to reproduce these 2 scenarios as well.

So I started thinking, and I may be wrong, but I think what might be happening is that Windows or Sandboxie is interpreting a wildcard symbol as meaning "Blank". As we all know, (atleast afaik..) you're not allowed to use "blank" folder names in Windows. Therefore, when using a setting such as "%Desktop%\Dir1\*\*", Sandboxie/Windows is interpreting it as "%Desktop%\Dir1\\".
Because of this part "%Desktop%\Dir1\\", Sandboxie/Windows is encountering an error because it is interpreting the folder as being a "blank" name (which isn't possible) and thus decides "Well there cant be a folder named blank, so lets go back one directory instead" and Sandboxie ends up applying the CFP setting to the previous folder, in this case Downloads/Dir1.

I'm not sure if thats actually the problem, I am just making a guess right now based on what I've seen.
Anyways I hope that made sense.
Maybe tzuk might know a bit more about whats going on than we do.

I can confirm this behavior on Windows 7 x64 and XP. It's been like this since at least 3.34 (the olden days).


Well, Sandboxie apparently doesn't collapse consecutive slashes into one. For example, this won't block anything because of the trailing slash in "C:\test\":

This surprised me before since I was used to command prompts and batch scripts, which do collapse consecutive slashes.

I'll check this out, hopefully tomorrow, and let you know what I find out.

I looked into how it works and I can explain this behavior now.

When a file is accessed at some path, Sandboxie checks the path against Open/Closed settings, but at the same time it also checks the sequence path\ (path with a backslash suffix).

The rationale is that if you may have added something like ClosedFilePath=C:\TEST\ and clearly that should still apply when the path in question is C:\TEST.

So you have these -

OpenFilePath=C:\Users\User\Downloads\*
ClosedFilePath=C:\Users\User\Downloads\*\*

And then you try to create a file

C:\Users\User\Downloads\TestFile.txt

And Sandboxie checks this path, but it also checks this other path:

C:\Users\User\Downloads\TestFile.txt\

And as you can easily see, this other path matches the ClosedFilePath setting.

So this explain the problem.

I don't really know what to do about this. I don't want to add some magic "match one or more" character because I feel that's going to be something arcane that only wraithdu and a handful other people would know or remember. So that's not going to be generally useful.

I also briefly considered checking for the path + backslash only if the check for just path (no backslash) matched nothing. But I think this will make Open/Closed paths look a bit unstable in some scenarios. For example,

OpenFilePath=C:\Test
ClosedFilePath=C:\Test\

here the test for C:\Test will match OpenFilePath, so there will not be a check for C:\Test\ . On the other hand,

OpenFilePath=C:\Test\
ClosedFilePath=C:\Test\

here the test for C:\Test will fail on both and then the check for C:\Test\ will match the ClosedFilePath.

Today, the two examples above have the same effect as both C:\Test and C:\Test\ are checked at the same time, first against ClosedFilePath, then against OpenFilePath.

To conclude this essay. I'm probably not going to do anything about this problem immediately. However if some good idea comes up, perhaps I'll explore it during the next beta cycle.

As a user, I would expect this to block C:\TEST only when TEST is a folder. C:\TEST\ makes no sense as a filename, as illustrated by:


So then, in the next example:

To me, C:\Users\User\Downloads\TestFile.txt\ clearly refers to a folder - so why is this second path checked when dealing with a file? My understanding is that slashes are path component separators and can't be part of a filename. (Reference on MSDN: Naming Files, Paths, and Namespaces)

I'm not a coder so I must be missing something important here...

I agree with Mike, there's no reason to check an existing file path with a trailing \. By the same logic, there's shouldn't be any reason to check an existing folder path without a trailing \. In your checking routines, you should probably remove any trailing \ from files and add a trailing \ to folders prior to the Open/ClosedFilePath matching. This should allow for both the desired and expected behavior.

For example, if I had ClosedFilePath=C:\TEST\, and the requested path is C:\TEST (the folder), then I would expect the logic to automatically add the trailing \ to C:\TEST.

However if I have ClosedFilePath=C:\TEST\*\*, and the requested path is C:\TEST\file.ext, then nothing should be added to the end of the path and it shouldn't match.

This still leaves a question with the last example when trying to create a new folder under C:\TEST. Logically you would expect the folder to be allowed to be created since we are accessing the folder level directly under C:\TEST, which like file access, is allowed. Afterwards, however, access to that subfolder should be blocked. The problem is, if we follow my suggestion above about adding a trailing \ to folder paths, then we will match the ClosedFilePath and the folder creation would be blocked.

So perhaps we need a two scenario approach:

1) Creating a new file or folder: Any trailing \ should be removed. Creating a folder should be the same as creating a file.
2) Accessing an existing file or folder: The trailing \ should be removed from files and added to folders.

This way we should get the desired behavior. We can create files and folders under a directory where access to subfolders is blocked. In the case of a new directory, subsequent access would be blocked.

I hope that makes sense. Doable?

Looks like I forgot to mention one very important thing, and that is that checking open/closed paths is almost the first thing Sandboxie does, so it can immediately decide between three approaches:

- Mach on ClosedFilePath: Immediately abort due to access denied
- Match on OpenFilePath: Route the request "as is" to Windows
- Otherwise: Full processing with sandbox folders

This check happens before Sandboxie knows if the file/folder exists or not, or if it is a file or a folder.

Now of course you might say -- so change it. But the thing is that emulating all the tiny details of Windows file access has been a lot of works over many years, even now it's not yet 100% perfect. I'm concerned about making any changes there, because almost almost every time I've made some change there, something else broke, and then I had to fix it again.

I did mean it when I said I'm open to ideas, but at the same time, like I said, I'm concerned about making large changes in this area.

That's totally understandable. I'm not sure I see a perfect solution here. Checking every path without and with the trailing \ seems to err on the side of restriction. While removing all trailing \ from paths would allow at least some kind of access to subfolders in a closed path, ie ClosedFilePath=C:\TEST\ would still allow at least enough access to get a handle to C:\TEST.

But on the other hand... perhaps with ClosedFilePath=C:\TEST\, access should be allowed to C:\TEST. Specifying a closed path with a trailing \ would say to me that access is only blocked to subfolders and files, not the directory itself. So in file manager terms, you could open the directory but it would appear empty.

Back to my original example:

OpenFilePath=C:\TEST\*
ClosedFilePath=C:\TEST\*\*

this would allow the desired access. I could create files and folders in C:\TEST\ and access the files and folders (although folders would appear empty). I would also be blocked from creating anything in those subfolders. That seems to make the most sense to me.

This does however raise some questions. Suppose I have both folders C:\TEST and C:\TEST2. What if I wanted to totally block access to C:\TEST? Previously you could do CFP=C:\TEST\ and be good to go. With the above change, you'd have to do CFP=C:\TEST, which would also block C:\TEST2, not the desired effect. This might require some changes to your wildcard (*) rules.

Consider:
1) A trailing * is no longer assumed unless the path spec ends in a \, similar to when a * appears somewhere in the middle of a path spec.
- CFP=C:\TEST (no assumed trailing *) would block access to C:\TEST itself (and everything inside), but not C:\TEST2.
- CFP=C:\TEST* would block access to both C:\TEST and C:\TEST2
- CFP=C:\TEST\ (assumed trailing *, same as C:\TEST\*) would block access to the contents of C:\TEST, but not the folder itself
2) All internal path matching is done without trailing \

I think overall this is more flexible than the current system, but I'm sure it will break some things. Although this is a beta test, so things like this should be able to be tweaked and changed.

Thoughts?

I'll leave the discussion of the nitty-gritty to more qualified folks, but I completely agree with wraithdu on the desired behavior.


This makes the most sense to me. If people want a *, they should add one. To make the transition to this new behavior, Sandboxie could hardcode the * into sandboxie.ini paths where it's currently assumed.

A side benefit is that we wouldn't need hacks like \Device*\HarddiskVolume1\ to avoid the automatic *.


If this is one of the easier fixes, would you reconsider?

I've come across situations where a single-character "?" wildcard (just like in the command prompt) would've been very useful. For example, since we can't ClosedFilePath a folder while making exceptions for a child folder, it would help to be able to specify paths more exactly. I think a "?" would add a lot of flexibility and be easy to remember. To specify "one or more", just use "?*".

Anyway, tzuk, I won't argue if you decide there aren't enough users to support this.

wraithdu I think you're going a little too far with this. I feel like on one hand I'm telling you that I'm not excited about making any non-trivial changes to the mechanism, and on the other hand it's like your thinking up these grandiose changes.

There could also be a couple of problems, or at least, stuff that needs extra attention:



Well if you can get a handle to the directory then you can enumerate the files in it. So this means the directory enumeration function has to be more strict than the file/directory open function. No big deal, just saying. For the same reason, it means C:\TEST can be opened and then renamed to C:\OTHER. So the rename function should be adjusted too. No big deal, just saying.

Just to point out that trivial changes might introduce all kinds of new problems, and eventually involve a lot more work than they seem. So again, I'm just concerned about changing anything beyond the most trivial bits.



If you don't have a trailing wildcard then it would block just C:\TEST and nothing else. The pattern matching is just path strings and wildcards. C:\TEST* matches C:\TEST\FILE, but C:\TEST simply does not match C:\TEST\FILE any more than it matches C:\TEST2.



But also I feel I should make progress in various areas in Sandboxie, rather than keep making changes to some particular area (like file access) and then have to spend even more time due to the ramifications of that.



Yes, in some sense I agree, but also I think it's a "purist" kind of change. It doesn't change much but can be a lot of headache to someone who doesn't stay up to date. How about if I add some special form that negates the wildcard at the end:

ClosedFilePath=|\Device\HarddiskVolume1\

I'm putting this and the single-character wildcard into the same "to do" item. No promises but I might do that at some point.

Sorry if it seems like I'm pushing, I don't mean to. I just thought if I could provide a better picture of what I'm thinking, then it would give you a better sense of what changes might be required. It's obviously non-trivial and I don't expect anything to change that would break or degrade current functionality. I think I've made my point, so I'll leave it at that.