Hello,

I have a new problem (new to me at least) and its the most unusual I've had to deal with.

I noticed chrome (19.0.1084.56) wouldn't display PDF's in its internal viewer. This is new so I
started to investigate.

After the usual - clear sandbox, try again, new vanilla sandbox, try again.. etc. I've narrowed it down
to a single specific behaviour

- With a single sandbox defined..

1) Enable "Force Google Chrome to run in this sandbox".
Run chrome from start menu or task bar.
All attempts to load PDFs or even print-preview will fail.
quit and delete sandbox contents.

2) Without changing anything, right click on the sandboxie tray icon, select the sandbox and select "Run Web Browser" (chrome is my default browser)
Same chrome starts up, same profile, in same sandbox.
PDF's now load fine
Print Preview works fine.

I can open a command prompts and use "c:\.....\chrome.exe" and I have PDF problems.. type "start.exe c:\.....\chrome.exe" and it works fine.

Same test, run the straight command line "c:\....\chrome.exe" from a sandboxed command prompt. no problem.

Why does a forced chrome behave differently to one run from any other method?

(Sandboxie 3.70 and 3.72)


Cheers.
Blacky.

I haven't looked into this yet, but how about if you try this -- use Run Any Program in Sandboxie to get some programs in the sandbox. And only then try to launch a forced-program instance of Chrome. Do you still see the problem with PDF?

yes, absolutely!

my sandbox is configured to auto-clear, so I left a command prompt running sandboxed and
retested.. no change in the behaviour.

form completeness, I normally run with chrome having full access to its profile directories.
I reset the sandbox to default and retested.. no change.

On a whim, i removed chrome and reinstalled it completely within a sandbox. it behaved normally then,
even running it from an icon on my desktop (shortcut path included c:\sandbox\...)

Regards

I couldn't duplicate the problem report, on XP.

With Chrome installed outside of any sandbox and set as the default browser:
It didn't matter if I ran Chrome forced (using a normal Chrome shortcut), or without changing anything if I used the Control tray icon menu > Run Web Browser.
In both cases, the built-in .PDF viewer was able to open .pdf files without any problem.

I allowed Chrome (19.0.1084.56) to save bookmarks, cookies, and preferences, out of the sandbox.

That's good. I'm hoping its something I'm doing wrong.

Of course I've omitted the following:

Windows 7 - x64
Chrome - 19.0.1084.56

I just recently enabled the 64 bit experimental protection but that was after I initially identified the problem, and
in the last day have had an unexpected bsod.

I've now installed all available windows-update patches. I'll disable the experimental protection (64bit) , and re-test.

I'll also test in a VM running a vanilla windows-7 x64 install.

I have one peculiarity which I'm starting to notice confuses more and more problems..

I have "C:" containing windows on SSD, and "D" containing everything else.

I have "SYMLINK" "C:\Users" -> "D:\Users". This is common enough but the recent versions of adobe acrobat
now crash.

I've also recently moved my sandbox folder from D:\Sandbox to C:\Sandbox, so I'll move it back and re-test..

David

I can confirm this is the source of the problem. Notes in how to reproduce included below...

As long as Chrome is launched via "C:\....chrome.exe", it is forcibly sandboxed and PDF plugin fails.
As long as Chrome is launched via "D:\....chrome.exe", it is forciblt sandboxed and PDF plugin works fine.

C:\Users\ is a SYMLINK to D:\Users, and chrome, without sandboxing, works perfectly either way.

Also, once manually sandboxed, it run's either way. Its some bad interaction between forced sandboxing of
apps which have symlinks in their path.

A super easy way to reproduce.

Windows 7 has a built in symlink in everyones profile called "Local Settings" which points to "Appdata\Local"

To Test:
Create a duplicate CHROME shortcut on your desktop.
Right Click -> Properties

Change the Target:
"X:\Users\ME\Appdata\Local\Google\Chrome\Application\chrome.exe" becomes
"X:\Users\ME\Local Settings\Google\Chrome\Application\chrome.exe"

(Change the "Start in" field in the same way.)


Apply/OK.

Double click - chrome starts fine.
Test PDF. Fails.
Quit.

Right Click->run sandboxed
Test PDF. Works.
Quit.

Scratch Head.

Can anybody who has a spare moment give this a quick test?
Thanks
Blacky

Thanks for the update! I'll probably need a week or two before I can look into it, but this should definitely help me reproduce the problem.

By the way, do you use Drop Rights? Can you check if it that setting also plays a part in this problem?

No problem.

Regarding Drop Rights, I never have it set, which is how it was configured when I first noticed the problem.
During my testing it became set, probably as a result of resetting my config to default.

It makes no difference to chrome either way.

The problem (I assume) may affect any program which is forced and has a symlink in its path, chrome was just
the squeakiest wheel in this case.

Regards
Blacky

Thanks for checking the Drop Rights thing. I thought maybe the symlink had permissions on it and the Drop Rights played some part in making it inaccessible for the program in the sandbox.

I will try to look into this during next week and post my findings.

I am having similar problems with another app. Here is my thread:
http://www.sandboxie.com/phpbb/viewtopic.php?t=13191

tzuk is going to check in with it.

The only workaround I know is to use the "Run any program sandboxed.lnk" shortcut that sandboxie makes when it's installed (you can make these again through preferences) and create shortcut to launch it in a different way than force programs/folder

Blacky, thank you again for posting your findings, I'm not sure I would have known what to fix otherwise.

The problem is that Sandboxie routinely "fixes" all paths it deals with, with and translates all symbolic links. This means that when you start Chrome.exe through Start.exe, then Chrome.exe always starts with a fully resolved path that doesn't use any symlinks, and when it starts a second Chrome.exe process, it is going to use the same fully resolved path.

When you run Chrome.exe as a forced program, it means the path in that first Chrome.exe isn't fully resolved, which is the scenario that you highlighted.

I was able to fix the problem, and the fix will be included in the next beta, which I plan to release very soon.

Please check if version 3.81.01 fixes your problem. Download here:
http://www.sandboxie.com/phpbb/viewtopic.php?t=13209

Hi tzuk,

Not sure if our problems are similar/same (as mentioned in http://www.sandboxie.com/phpbb/viewtopic.php?t=13191) but 3.81.01 did not solve the xrecode2 mp3 conversion problem when using force program, instead of "run sandboxed" or custom shortcut.

Sorry for the delay. Will test 03 beta immediately.

I'm pleased to say that my specific problem with chrome is fixed in the 3.81.03 beta release.

Thank you very much.

I rolled it back to 3.72 to double check my test scenario, and it failed as expected.

Good work! Looking forward to the next release!

Blacky