Forced folder bug

[Dun]

Outside sandboxie folder behave like forced folder when it should not.

How to reproduce:
1. Download some simple installer .exe/.msi and save it to desktop (unsandboxed path) [in my case CCleaner free]
2. Run installer in clean TEST sandbox and install the app
3. Run unsandboxed explorer, navigate to path where app has been installed [C:\Sandbox\*\TEST\drive\C\Program Files\CCleaner]. App shoud run sandboxed and it's ok.
4. Close it (make sure the app doesn't stay in background like taskbar icon), move (cut-paste) whole app folder to unsandboxed desktop
5. Open (unsandboxed) app folder and start the application. It will run sandboxed in your TEST sandbox (even if path is outside of sandbox now). Whole app [CCleaner] folder behaves like forced folder (for all executables) for TEST sandbox which is really old bug.

[any simple application, CCleaner, CPU-Z]

[nanana1]

After step 4, can you reboot your PC before running step 5 and report back if step 5 bug still happen after reboot.

[btm]

I was able to duplicate this 'issue' on my Windows 7 x64 system and I eliminated a few possibilities. SbieSvc and the gui are not involved. That leaves Windows itself (the one I'm leaning toward) and the sbie driver. After a reboot if you cut and paste the folder before sandboxie ever runs anything from the folder it is still protected so this is why I'm inclined to think it is more likely windows is responsible. Either way it could be related to some sort of handle issue in the sandboxie driver or more likely, such as when using disk management and removing or changing a drive letter, it is still available from the old path until the next reboot in certain cases. I doubt it's a 'sandboxie' handle issue because sandboxie still protects paths that aren't loaded at boot and has never caused my system to be unable to safely remove a drive even after a path from a removable hdd was used. I really do think it's somehow related to how windows and/or ntfs works and not sbie in particular.

A reboot after the move fixes it either way so I'm not concerned.

[Curt@invincea]

I just tried this with CC. As long as I kill the ccleaner.exe that is running in the background inside the sandbox, the new ccleaner.exe runs outside the sandbox.

[btm]

Just in case, as you weren't very specific with your test method, copying the directory to a diff directory won't cause this issue. Cutting and pasting the folder does. Eg "C:\Program Files\Test1\Test2\test.exe" with "C:\Program Files\Test1\Test2\" being a forced folder. Running the test app and then closing it, followed by cutting and pasting the Test2 folder so that it exists as "C:\Program Files\Test2\" then launching the test exe from the new folder location manually does it for me every time. Subsequently renaming the same directory STILL leaves it protected by sandboxie and it continues on like this any time a CUT and paste is used until reboot. It'd be nice if you could reproduce it to see what he meant (and verify if sandboxie is not at fault).

I just retested it with a FAT XP install followed by an NTFS XP install, happened on both so it is def not 'NTFS specific' after all. That leaves windows or sbie. Either way it's not something I'm actually concerned about but the fact you weren't able to reproduce it makes me think you did it wrong!

[Dun]

I just tried this with CC. As long as I kill the ccleaner.exe that is running in the background inside the sandbox, the new ccleaner.exe runs outside the sandbox.

Ok, my fault, some time has passed since I reported this for a first time http://forums.sandboxie.com/phpBB3/view ... 89#p105389 I've experienced some issues with latest CCleaner. However it was possible to reproduce the issue with 4.x CCleaner version.

So I decided to record the video on my crappy netbook, so my apologies for low video quality.
https://youtu.be/bedwlZhvGX4

CPU-Z is unable to load the driver but it does not really matter in this case - issue can be reproduced same way.

Here is my configuration:
http://pastebin.com/ZBfRBnfV

Also the tread title may be a little bit confusing as forced folder option should not be used. If you find any better title that is short enough, please feel free to change it.

[Curt@invincea]

I just ran through the same steps. I can't tell exactly what you are doing because it is in Polish and you have a bunch of other apps that have added to the R-click context menus.

I downloaded IrfanView into the sandbox. I r-click and select copy the InfraView folder. If I "Paste" the IrfanView folder onto the desktop, the exe will run outside the sandbox. If I "Paste shortcut" onto the desktop, the exe runs in the sandbox.

I think you have something on your machine that makes this copy behave like a copy shortcut. Can anyone else try these steps to verify what I am seeing?

When you look at the properties for i_view32.exe, is it located on your desktop?

IrfanView.jpg (69.89 KiB) Viewed 2016 times

[Dun]

Oh, c'mon that one should be simple. Setup has been downloaded using sandboxed browser, moved by IDM do the unsandboxed desktop. Then using content menu setup started inside of abc sandbox. The program has been executed inside of the sandbox - it was ok. After that whole folder has been moved (cut -> paste; not copied) to desktop. The bug is that something wrongly thinks that moved folder and executables are still inside sandboxed path while they are not.



Most likely you won't reproduce this if you copy a folder.

Paths are shown on the video and yes it was unsandboxed desktop.

[Curt@invincea]

Ok, cut and paste produces the same thing for me. I can't repeat the problem. It runs outside the sandbox just like it is supposed to. Perhaps IDM is causing this -- I don't use it.

What are the contents of your user's desktop folder? Do you see an IrfanView folder and all its contents? Did you look at the properties of i_view32.exe like I asked? Have you tried this without IDM?

[Curt@invincea]

Sandboxie does not keep track of files you copy out of the sandbox. When you start an exe outside Sbie, Sbie has no way of knowing that it used to be in the sandbox.

[btm]

I would have expected some sort of locked file issue to occur if sandboxie was the culprit but my original findings attempting to duplicate his stand. It's not 'just' folders moved from the sandbox directory that show this issue as I was easily able to reproduce it with the C:\Program Files\Test1\Test2 folder example I gave above over multiple OS's. I still think it may have to do more with windows and like I've said before, it's not a big deal either way. What has gotten on my nerves by even being a part of this thread and reading what followed is that it seems my time, tests to eliminate certain things, example of how to re-create and ultimately - notes were either skimmed over and not understood or completely ignored. I made the 'CUT' and paste point quite clear and yet you still tried to copy and paste it...again?! =( I'll happily make a nice little windows step recorder session for you if needed.

*update: I went ahead and created the psr...it was greater than the 2MB limit on uploads of this forum so I was forced to upload it elsewhere: http://www.mediafire.com/download/c3gl5 ... olders.zip

[Dun]

Ok, cut and paste produces the same thing for me. I can't repeat the problem. It runs outside the sandbox just like it is supposed to. Perhaps IDM is causing this -- I don't use it.

What are the contents of your user's desktop folder? Do you see an IrfanView folder and all its contents? Did you look at the properties of i_view32.exe like I asked? Have you tried this without IDM?

Yes, I see an IrfanView folder and all its contents. Yes, the properties are underlined red to the left on the screenshoot I posted above.
Of course I've tried this without IDM. This is one of the first bugs/issues I have ever had with Sandboxie. I use your app since 3.64. I won't argue about this but I think such behavior was there since always...

Maybe it's prefetch issue or some other mechanism?

Just in case, as you weren't very specific with your test method, copying the directory to a diff directory won't cause this issue. Cutting and pasting the folder does. Eg "C:\Program Files\Test1\Test2\test.exe" with "C:\Program Files\Test1\Test2\" being a forced folder. Running the test app and then closing it, followed by cutting and pasting the Test2 folder so that it exists as "C:\Program Files\Test2\" then launching the test exe from the new folder location manually does it for me every time. Subsequently renaming the same directory STILL leaves it protected by sandboxie and it continues on like this any time a CUT and paste is used until reboot. It'd be nice if you could reproduce it to see what he meant (and verify if sandboxie is not at fault).

I just retested it with a FAT XP install followed by an NTFS XP install, happened on both so it is def not 'NTFS specific' after all. That leaves windows or sbie. Either way it's not something I'm actually concerned about but the fact you weren't able to reproduce it makes me think you did it wrong!

You are right. I created new 123 sandbox, and C:\a folder, then placed GPU-Z there, made it forced folder, ran the GPU-Z - started inside, closed it, renamed the folder to b. GPU-Z still run inside 123 sandbox.

Thank you btm for your time and engagement! I really appreciate that.

It's not 'just' folders moved from the sandbox directory that show this issue as I was easily able to reproduce it with the C:\Program Files\Test1\Test2 folder example I gave above over multiple OS's.

I was able to reproduce this issue on over 15 years old PC with XP running. Both my way with InfraView (setup) I and btm's way with GPU-Z (renamed folder). In other words if you already place InfraView folder to the desktop and try to run the app you will see it run sandboxed. Then you can rename the folder and you'll see it does not change anything.

Why I think it's a problem? If any app installer can not be extracted by 7z, then I install apps in sandbox and then move their folders outside. These are two simple ways to make apps portable

Do you want me to reproduce the issue on your machine via TeamViewer, @invincea?

[nanana1]

Now I just tried to reproduce the Forced Folder bug and can reproduce the reported bug :

1. Create a forced folder
2. Download any program, eg. irfanview (iview438_setup.exe) and place it in the forced folder
3. Double-click on the program within the Forced Folder to install (of course, the program would install itself with the Forced Folder sandbox)
4. After installation completed, the program runs in the Forced Folder sandbox
5. Explore the contents of the Forced Folder sandbox and locate the irfanview program folder
6. CUT & paste the irfanview program folder to desktop which is not protected by Sandboxie
7. Open the irfanview program folder and double-click on i_view32.exe

You will notice that i_view32.exe run within the Forced Folder sandbox even though it was located on the desktop which is not protected by Sandboxie.

Hope you can now reproduce this Forced Folder bug.

On Win7 SP1 - 64bit

[Craig@Invincea]

I'll see if I can recreate the issue.

[Craig@Invincea]

Now I just tried to reproduce the Forced Folder bug and can reproduce the reported bug :

1. Create a forced folder
2. Download any program, eg. irfanview (iview438_setup.exe) and place it in the forced folder
3. Double-click on the program within the Forced Folder to install (of course, the program would install itself with the Forced Folder sandbox)
4. After installation completed, the program runs in the Forced Folder sandbox
5. Explore the contents of the Forced Folder sandbox and locate the irfanview program folder
6. CUT & paste the irfanview program folder to desktop which is not protected by Sandboxie
7. Open the irfanview program folder and double-click on i_view32.exe

You will notice that i_view32.exe run within the Forced Folder sandbox even though it was located on the desktop which is not protected by Sandboxie.

Hope you can now reproduce this Forced Folder bug.

On Win7 SP1 - 64bit

Alright, I did this with (2) test programs. One was Skype and the other was ccleaner. Followed the same steps as you have listed (minus the irfanview.exe program, but you suggested ANY program) .......and I did not get an sort of sandboxed behavior when I cut and paste to the desktop from a forced folder. When I run the cut program from the unprotected desktop, it runs normally. Anyone else??

Windows 7/64. SBie 4.19.4