Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UseNewSymlinkResolver causes applications to create both the link and the target folder #3481

Closed
offhub opened this issue Dec 6, 2023 · 38 comments
Labels
already fixed Already fixed at some point Symlinks Collection of symbolic links issues

Comments

@offhub
Copy link
Collaborator

offhub commented Dec 6, 2023

Describe what you noticed and did

UseNewSymlinkResolver causes applications to create both the link and the target folder in the sandbox. As a result, changes made to applications may not be saved properly.

  1. Create a symlink for Edge\User Data folder

from unsandboxed cmd:

cd /d "%LOCALAPPDATA%\Microsoft\Edge"
xcopy /e /y "User Data\" "%TEMP%\User Data\"
ren "User Data" "User Data.BAK"
mklink /D "%LOCALAPPDATA%\Microsoft\Edge\User Data" "%TEMP%\User Data"
  1. Run Ms Edge in sandbox
  2. The "User Data" folder is created in both locations within the sandbox.
  3. Use Windows Explorer to browse to both locations.

from sandboxed Windows Explorer:

%TEMP%
%LOCALAPPDATA%\Microsoft\Edge

from unsandboxed Windows Explorer:

C:\Sandbox\user\DefaultBox\drive\C\Users\user\AppData\Local\Temp\User Data
C:\Sandbox\user\DefaultBox\user\current\AppData\Local\Microsoft\Edge\User Data

How often did you encounter it so far?

Every time

Affected program

msedge, firefox, etc.

Download link

Not relevant

Where is the program located?

The program is installed only outside the sandbox.

Expected behavior

A symbolic link folder should only be created in a single location within the sandbox.

What is your Windows edition and version?

Windows 10 Pro 22H2 64-bit (19045.3693)

In which Windows account you have this problem?

A local account (Administrator)., A Microsoft account (Administrator)., An account with UAC protection set to Always notify.

Please mention any installed security software

Microsoft Windows Defender

What version of Sandboxie are you running?

Sandboxie-Plus 1.12.3 64-bit

Is it a new installation of Sandboxie?

I recently did a new clean installation.

Is it a regression?

No response

In which sandbox type you have this problem?

All sandbox types (I tried them all).

Can you reproduce this problem on a new empty sandbox?

I can confirm it also on a new empty sandbox.

Did you previously enable some security policy settings outside Sandboxie?

No response

Crash dump

No response

Trace log

No response

Sandboxie.ini configuration

UseNewSymlinkResolver=y
@offhub offhub added Confirmation pending Further confirmation is requested Symlinks Collection of symbolic links issues labels Dec 6, 2023
@DavidXanatos DavidXanatos added ToDo To be done High priority To be done as soon as possible fixed in next build Fixed in the next Sandboxie version and removed ToDo To be done High priority To be done as soon as possible Confirmation pending Further confirmation is requested labels Dec 11, 2023
@profucius
Copy link

profucius commented Jan 18, 2024

I believe I've found a regression on this ticket. This issue persists on every version between 1.12.4 and the current 1.12.7. The issue did not exist on 1.12.3. I found this ticket while reading the changelogs on 1.12.4 looking for any reason this may be happening.

Situation: I use a specific app (Obsidian, a markdown editor) within Sandboxie to create "profiles" of that app, so that I can run multiple instances of it at once. Instead of duplicating the data between the profiles, I use symbolic links to share folder access between all of them.

On Sandboxie 1.12.3, this worked perfectly fine.
However, on 1.12.4, this functionality breaks.

On .4, the app Obsidian (ran within the sandbox), it seems that Obsidian is seeing the symbolic linked folder as a folder, but it does not see any content within it. On .3, all content within showed fine.

Nothing else changed within Obsidian or the symbolic links. The only change made in my testing was installing the update for .3 to .4

Below I have provided a couple of screen captures demonstrating this issue. Take particular notice within the Obsidian app, left sidebar, the "Symlink" (folder) toggles open and shows a file called "Sym Text.md" within .3 , but within .4 the folder toggles open and is empty. No files can be found.

Let me know if I can provide any other information. If I need to open a new ticket for this, I will do that too. Thank you.

Working on 1.12.3

works-3.mp4

Broken on 1.12.4

broke-4.mp4

@isaak654
Copy link
Collaborator

For the record, I cannot play both videos on Microsoft Edge and Firefox, but fortunately it is possible to save them locally.

@isaak654 isaak654 reopened this Jan 19, 2024
@isaak654 isaak654 added Confirmation pending Further confirmation is requested ReOpened Reopened for another look and removed fixed in next build Fixed in the next Sandboxie version labels Jan 19, 2024
@DavidXanatos
Copy link
Member

what can you play them with my VLC fails

@DavidXanatos
Copy link
Member

@profucius could you write down a manual test case how to create the sym links and how to test without the software,
perhaps using cmd.exe only

@isaak654
Copy link
Collaborator

what can you play them with my VLC fails

Both videos work fine with K-Lite Codec Pack Mega.

@profucius
Copy link

profucius commented Jan 22, 2024

Apologies for the videos not working for you. I converted them using Adobe Media Encoder to reduce the file size, using one of the built-in codecs. It uploaded fine and plays in my browser fine, so I didn't realize it would be an issue. Glad you could at least view them via download though. PS- If you can recommend a better screen capture and upload tool, I'll take a look at it.

As for replicating the issue, I tried using multiple tools to create the symbolic links. Windows has its own built-in cmd line commands, and there is a shell extension tool that I prefer. It does the exact same thing as the commands but adds shortcuts to them. You can just right-click a file/folder and click "Pick Link Source", then go to the destination and right click and "Drop As" a symbolic link. To be clear, I am only creating symbolic links, not junctions or hard links or any other type.

Windows Explorer loaded within the sandbox is able to see through the symbolic links I created as expected. It may be the case that most softwares work just fine with the changes made in 1.12.4. However the Obsidian app demonstrated in my video is apparently an incompatibility with the change in 1.12.4 and therefore breaks. And unfortunately I rely on Sandboxie for Obsidian exclusively.

I hope that is the information you're looking for, but if you need anything else let me know. It may only be possible to reproduce the issue by installing Obsidian within a sandbox for yourself. It is a free software.

@profucius
Copy link

profucius commented Jan 22, 2024

Update: I just tried an idea I had and it gave me a rather bizarre result. Perhaps this will help in diagnosis.

I created an empty folder and named it Symlink. I placed that folder at the root of the same partition as the Sandboxie sandbox. Inside that empty folder I just created an empty file called Sym Text.txt. I duplicated this folder and placed it at the root of a different partition. So now there are two exact same dummy folders and files, but on different partitions. And I created a symbolic link of each folder into the sandbox, I named the one on the same partition Symbolic Link Same and the one on the different partition Symbolic Link Different.

On Sandboxie 1.12.3, the symbolic link created from the folder on the different partition is showing data as expected, but the symbolic link created from the folder on the same partition is not showing anything at all, as if it were empty.

What is bizarre is that on 1.12.4, this is reversed. The different one shows nothing, and the same one shows correctly. Screenshots below to show what I mean.

Again I'm quite confused by this, but perhaps it will help in diagnosis. Let me know if I can provide anything else.

1.12.3

1 12 3

1.12.4

1 12 4

@DavidXanatos
Copy link
Member

So you created the saylinks with an unsandboxed explorer, correct?

@profucius
Copy link

So you created the saylinks with an unsandboxed explorer, correct?

Correct, the symlinks are created outside of the sandbox / on the host OS. The above findings are within the sandbox.

@DavidXanatos
Copy link
Member

I created the links like you and cant reproduce the issue,
could yo please post your sandboxie.ini

@profucius
Copy link

#
# Sandboxie configuration file
#

[GlobalSettings]

[UserSettings_0D16022D]
SbieCtrl_AutoStartAgent=SandMan.exe -autorun
BoxGrouping=:DefaultBox

[DefaultBox]
Enabled=y
BlockNetworkFiles=y
RecoverFolder=%{374DE290-123F-4565-9164-39C4925E467B}%
RecoverFolder=%Personal%
RecoverFolder=%Desktop%
BorderColor=#00FFFF,ttl
Template=OpenBluetooth
Template=SkipHook
Template=FileCopy
Template=qWave
Template=BlockPorts
Template=LingerPrograms
Template=AutoRecoverIgnore
ConfigLevel=10

@DavidXanatos
Copy link
Member

well well that looks all right, strange that I cant reproduce it...
could you please test if the issue appears also with a completely empty sandbox?

@profucius
Copy link

profucius commented Jan 22, 2024

Yes I have tried a completely empty sandbox. Same issue.

Try these steps to reproduce:

  1. Create a blank sandbox.
  2. Install and run Obsidian within sandbox.
  3. When it asks, create a new vault.
  4. Choose destination for vault to be on the C:\ drive (anywhere, root is fine)
  5. When interface opens you should see a Welcome note.
  6. Now go to a folder (in Windows, not in sandbox) within another partition (e.g. D:\) and either pick an existing folder or create a new one.
  7. Create a symbolic link of that folder and drop it into the Obsidian vault folder within the sandbox, should be the one you created at C:\
  8. Within that folder you symbolic linked, create a new .txt file.
  9. Look in Obsidian, left sidebar, you'll see the symbolic linked folder name, but nothing inside when you expand it.
  10. Now repeat steps 6-8 above, but this time instead of D:, create & use a folder in the same partition as the sandbox (e.g. C:\)
  11. Make sure you have a dummy .txt file in this second folder too.
  12. Now you'll see that symbolic linked folder in the sidebar within Obsidian, but when you expand the folder you will see the dummy .txt file that you created within.

The results of this on your computer should look similar in concept to my most recent screenshots above.

This demonstrates that the issue with Sandboxie is that it is passing data through symbolic links properly when the source folder is on the same partition as the sandbox, but it does not do this properly when the source folder is on a different partition as the sandbox.

@DavidXanatos
Copy link
Member

@profucius how do we continue?
I cant reproduce the issue see my video.

@profucius
Copy link

Apologies it's been a busy few days. I am surprised you weren't able to reproduce the issue. It looks like you did things correctly in the video. I tried it on two local machines of mine and both had the issue. I'll try again soon when I have a chance and post an update. If I can't find a way to detail a reproduction then I'll just assume at that point it's something on my end. Thanks

@profucius
Copy link

profucius commented Jan 27, 2024

I re-watched your video and noticed you were installing Obsidian directly into the sandbox. I actually am not doing that, I install Obsidian on the host OS and run it within the sandbox. I tried reproducing the results by installing Obsidian directly into the sandbox like you did, but it did not make a difference. I wonder though, if you installed Obsidian within the host OS, would it change anything for you?

Also, what Windows version are you testing on? I'm on Windows 11 Pro 23H2 with Jan 2024 updates.

Edit: I just tried the whole process on a Windows 10 Pro 22H2 setup, sandboxie 1.12.7 and Obsidian installed within sandbox. Same original issue. I cannot seem to reproduce your success in your video no matter which machine or OS I try. Very strange...

@DavidXanatos DavidXanatos added the fixed in next build Fixed in the next Sandboxie version label Jan 28, 2024
DavidXanatos added a commit that referenced this issue Jan 28, 2024
@DavidXanatos
Copy link
Member

Could all please test the latest CI build to see if all works well now with symlinks

@profucius
Copy link

Could all please test the latest CI build to see if all works well now with symlinks

How do I find this? I looked around the repo but I am not seeing it

@DavidXanatos
Copy link
Member

@profucius
Copy link

profucius commented Jan 28, 2024

https://github.com/sandboxie-plus/Sandboxie/actions/runs/7687015021

I downloaded the x64 package from that link. Uninstalled current sandboxie. Extracted zip and ran the SandMan.exe. It asked to do initial configuration. Then gives me this error.
image

I've tried manually starting the driver from the maintenance menu and it still tells me this error. Am I doing something wrong? This is my first time running a prerelease build of sandboxie.
image

@DavidXanatos
Copy link
Member

DavidXanatos commented Jan 28, 2024

Yes you do, the driver in CI build is not signed.
So you need to enable test signing bcdedit /set testsigning on on your system and reboot, or what usually is enough use the signed driver from the last proper release. As long as the driver does not change, that works just as well.

@isaak654
Copy link
Collaborator

isaak654 commented Jan 29, 2024

I confirm that the fix is effective if you create a copy of the vault folder, delete the sandbox content, and restore the vault folder later.

These steps were mandatory in order to get Obsidian working from the CI build.

@profucius
Copy link

profucius commented Jan 29, 2024

I tried the testsigning command and rebooted. I was able to run the portable sandboxie, however my sandboxies could not run any apps. Nothing would open and a WerFault.exe ran for a few seconds before everything closed inside SandMan. Even tried running the obsidian installer in a fresh sandbox, same issue. It's plausible this is related to my setup somehow, however when I reverted everything back to official 1.12.7 exes ran fine again. I can try again on my other fresh machine later when I get time.

@offhub
Copy link
Collaborator Author

offhub commented Jan 31, 2024

I haven't tried it with programs other than browsers, but browsers with symlinked profile folders no longer open in the sandbox after this fix. (1.12.8)

Setting UseNewSymlinkResolver=n does not solve the problem.

@echo off
:: Run as Admin

if exist "%TMP%\Microsoft\Edge\User Data_3481\" (
	rd /s /q "%TMP%\Microsoft\"
	rd "%LocalAppData%\Microsoft\Edge\User Data\"
	ren "%LocalAppData%\Microsoft\Edge\User Data_3481_BAK" "User Data"
) else (
	xcopy /e "%LocalAppData%\Microsoft\Edge\User Data\" "%TMP%\Microsoft\Edge\User Data_3481\"
	ren "%LocalAppData%\Microsoft\Edge\User Data" "User Data_3481_BAK"
	mklink /D "%LocalAppData%\Microsoft\Edge\User Data" "%TMP%\Microsoft\Edge\User Data_3481"
)
sbie3481_20240131_185351.mp4

@offhub offhub reopened this Jan 31, 2024
@offhub offhub removed the fixed in next build Fixed in the next Sandboxie version label Jan 31, 2024
@DavidXanatos
Copy link
Member

@offhub
pleae remove UseNewSymlinkResolver=n
the goal is for all to work with UseNewSymlinkResolver=y which is the default
UseNewSymlinkResolver=n is the old sbie behaviore which is bugged

@offhub
Copy link
Collaborator Author

offhub commented Jan 31, 2024

I've tested without UseNewSymlinkResolver=n.

@isaak654
Copy link
Collaborator

I wonder if it wouldn't be possible to write unit tests to be run as part of the workflow steps, otherwise the risk is chasing these regressions all the time.

@JaGitU
Copy link

JaGitU commented Jan 31, 2024

Seems SymlinkResolver is broken in the newest version (5.67.8)
The following batch worked fine before. Launch it under default sandbox and try to open SymLinkDir in the explorer window appeared, now it crashes.

mklink /j "%~dp0SymLinkDir" "%~dp0"
explorer "%~dp0SymLinkDir"

@DavidXanatos
Copy link
Member

@offhub
Copy link
Collaborator Author

offhub commented Jan 31, 2024

Looks good to me.

@JaGitU
Copy link

JaGitU commented Jan 31, 2024

please try this hitfix build: https://github.com/sandboxie-plus/Sandboxie/releases/download/v1.12.8/Sandboxie-Plus-x64-v1.12.8b.exe

Now it’s good. Just using the opportunity would like to pay you attention on old unresolved issue #3178 that still exists (sorry for off-topic:)), hope it will be fixed in the future builds somehow.

@profucius
Copy link

please try this hitfix build: https://github.com/sandboxie-plus/Sandboxie/releases/download/v1.12.8/Sandboxie-Plus-x64-v1.12.8b.exe

I'll give this a try tomorrow; I had some trouble with my other machine disabling driver signing but will give it another go.

@DavidXanatos
Copy link
Member

1.12.8b has a signed driver only the installer and sbiedll.dll are unsigned

@profucius
Copy link

profucius commented Feb 1, 2024

I've test 1.12.8b this morning and found an unusual behavior.

  • Started with a fresh sandbox.
  • Ran Obsidian within it. (already installed to Host OS)
  • Created a new vault in Obsidian when prompted.
  • Set the vault folder at the root of D: (D:\Symvault)
  • Created two empty folders on the Host OS. 1) D:\Symfolder D and one V:\Symfolder V (actual partitions on Host OS)
  • Created symbolic links using HardLinkShellExt for both folders into the sandbox/drive/D/Symvault folder.
  • Created an empty file within both folders and named them Symfile D.md and Symfile V.md respectively.
  • Good news is that both folders and files show up inside Obsidian now.
  • Up to now, this was not working on 1.12.7, It would show the contents of symbolic links on the same partition, but nothing for anything on a different partition.
  • However, now there is a new, breaking behavior:

When I type text into either one of these files, D or V, Obsidian shows the typed text. However when I look at either of these files in the Host OS filesystem, they show as 0kb filesize. If I open them with notepad.exe they are blank. I explored the sandbox folder structure in the Host OS and found that Sandboxie is creating a duplicate of each of these files upon being edited and placing them into sandbox/drive/D/Symfolder D/Symfile D.md and sandbox/drive/V/Symfolder V/Symfile V.md respectively.

This is a problem because it defeats the purpose of the symbolic links; If the files are automatically duplicated to inside the sandbox upon edit, then the contents of those files will no longer be accessible outside of the sandbox. This is why I am creating them as symbolic links, to remain accessible to other applications on the Host OS.

My Sandboxie.ini does not contain any lines at all with UseNewSymlinkResolver

Screenshots demonstrating my findings:

image

Originally created files, showing as zero kilobytes in size:

image

image

Automatically duplicated files by the sandbox upon edit, showing as one kilobyte in size due to containing "Text as file contents"

image

image

@offhub
Copy link
Collaborator Author

offhub commented Feb 1, 2024

Sandboxie does not allow direct writing to host system files without the OpenFilePath directive. It would be better to use OpenFilePath instead of Symlink.

OpenFilePath=D:\Symfolder D\
OpenFilePath=V:\Symfolder V\

@profucius
Copy link

profucius commented Feb 1, 2024

I just retested using the OpenFilePath instructions above. I was able to get everything working as expected on 1.12.8b. With a caveat

OpenFilePath instead of Symlink

This does not work. I put the directories in and deleted the symbolic links, and Obsidian app was completely empty. I added the symbolic links in again, and now when I edit the files within Obsidian, it writes directly to the original files and does not create duplicates/forks of them.

Going forward I will use OpenFilePath and Symbolic links in tandem to fulfill these needs. If it remains stable like this, then I will consider it resolved from my end. Thank you all

@isaak654 isaak654 added already fixed Already fixed at some point and removed Confirmation pending Further confirmation is requested ReOpened Reopened for another look labels Feb 17, 2024
@sandboxie-plus sandboxie-plus locked and limited conversation to collaborators Feb 17, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
already fixed Already fixed at some point Symlinks Collection of symbolic links issues
Projects
None yet
Development

No branches or pull requests

5 participants