1) Very often SB cannot unload the registry hive when the last process terminates or you use "Terminate All....". An error message is poping up. If you check the open files (with OFView.exe as an example) you can see that some SB process still has the registry hive in use.

2) Is it new that I can access network drives from within SB ?
I started a sandboxed cmd.exe and change drive to a network drive
( in my case H: ). There I did the following command:

dir > test.txt

I expected an error message as in 2.64 but I was very surprised that
I could load the file into notepad modify it and save it again.


The file was changed on the real network drive (I checked this from
outside SB) and there was no H subfolder in the Sandbox Root drives
subdirectory.

Network access is very dangerous as a virus could spread to the
network and delete thousands of files.

Either disable network access or even better make it possible to
configure it. Something like

AllowedNetworkDrives=H,P
or
AllowedNetworkpath=\\server\share,server2\share

3) Try to install JRE 6.0 inside SB. It fails after around 20% of installation
with a strange message (something about internal error) from the
Installer-Package.


Any ideas about these problems ?

Regards,
Oliver

@tzuk
I didn't found in the faq anything about

AllowedNetworkDrives=H,P
or
AllowedNetworkpath=\\server\share,server2\share

how may undocumented settings are there more?


Owen

Owen.

They don't exist but it would be nice to have them. So this explains why you didn't find them in the FAQs

This doesn't happen for all kinds of shares. I have a UNC share published by Server 2003 and it gets sandboxed just fine on access from XP.

(In other words, not read-only access like in 2.64, the newer Sandboxie properly sandboxes remote shares just as well as local drives.)

What's the nature of the remote share? Could it perhaps a DFS share? I don't have these so I just ignore their existance.

In any case I recommend you run a Sandboxie Trace with FileTrace=i (for "ignored" devices) and it should report the name of the device and its type, then I can revise Sandboxie to include sandboxing for that kind of devices as well.

Look for a line that says (FI) in the trace log.

Tzuk

The filer is not a Windows 200x server but is an EMC Celerra High-End NAS Storage System. It is part of our company environment and we use it since years without any problems. It has the newest possible firmware.

I could narrow the problem down a little bit.

1) I started SB
2) I Launch a sandboxed cmd.exe
3) I change drive to H: (H: + ENTER)
4) I do a dir (Contents of real H: is listed)
5) I do a dir > test3.txt (Works. test3.txt with content created on real H: but not in E:\Sandbox\DefaultBox\drive)
6) I open a sandboxed notepad.exe
7) I do a File->Open and try to access by using the UNC path \\zelerra2\rehmann2k\test3.txt (I get access denied)
8 ) I use H:\test3.txt and the file opens fine. I can modifiy and save it.
9) From this point on the file is correctly created in the Sandbox are E:\Sandbox\DefaultBox\drive\H\test3.txt

Now the strange thing comes.

I close all sandboxed processes (cmd.exe, notepad.exe)

10) I again open a sandboxed cmd.exe
11) I again change to H: (H: + ENTER)
12) I again do a dir

Upppssss.. I only see the contents of my sandboxed H: drive (whats in E:\Sandbox\DefaultBox\drive\H)

13) I again open a sandboxed notepad.exe and try to open my test3.txt.
14) Notepad as well only sees the sandboxed H: in the File->Open dialog.


It seems that SB has several problems:

A) It treats H: and \\ZELERRA2\REHMANN2K ( =H: ) differently even if they are the same UNC network path in background.

UNC Path gives access denied
Drive Letter seems to correctly sandbox

BTW, how would SB sandbox files if somebody does not use drive letters but only UNC path ????

B) When you first open a sandboxed cmd.exe and step to a network drive SB clearly writes through to the real network drive. (not good )

C) When you close and open again (notepad.exe, cmd.exe) SB isolates them to the sandboxed H: for READ requests instead of passing them through to the NAS system.

I have attached the debug traces where I did some of these actions.
Hope this helps.

Regards,
Oliver

You think? There's so much information in your last couple of posts, my head spins.

* * *

I ran a similar test on Win2000, I see same results as what I get on XP:

Remote shares, mapped through a local drive letter, are sandboxed just fine.

Remote shares accesses as \\server\share can be read, but not always. As you observed, this breaks down if there are already sandboxed items for a local drive letter corresponding to that remote share.

But either way and in any case I couldn't write anything on a remote share. Either it goes to the local sandbox or I get "file not found" errors, but the write does not occur.

* * *

As for the trace, I'm not sure, but it may be that access through the PIPE devices listed, provide a secondary way for your computer to place files on the remote share.

So let's try the following addition to your Sandboxie.ini, in that sandbox-specific section:

ClosedFilePath=\Device\Mup\*\PIPE\wkssvc
ClosedFilePath=\Device\Mup\*\PIPE\srvsvc

You'll need to Reload Configuration but you probably know this already.

Does this block the access?

Oh . . . Sorry ... On second review I see these were already denied access in the trace.