CrossOver Support - Community Forums

Fairly new crossover user here(basically since GPTK got integrated), but long time mac/linux/win engineer. I do not understand nor agree with the default "integration" that crossover provides with the host filesystem.

The sane defaults for code/application injection technologies such as crossover must be the principle of least privilege. To my horror, I discovered that crossover sets each bottle with access to:

1. Documents, Pictures, Music, Movies, Downloads.
2. any and all currently mounted volumes. This includes private/encrypted volumes as well.
3. The entire user mac home folder is mounted as the "y:" drive.
4. The root "/" is mounted as the "z:" drive

I'm not sure who thought this is a good idea, but I find it incredibly careless and not at all customer-oriented. Let's face it - the use for Crossover on mac is to run games. As such, I absolutely do not consent to this. There is absolutely 0 value or valid reason to share my entire mac with some random game. Some of us do not have dedicated macbooks for gaming which are free of any sensitive files. We have sensitive private documents, images, etc, including potential 3rd party private information.

Unfortunately, I have no way to disable this behavior. Even manually remapping things (swap symlinks, edit config, fidgeting with the "Wine Configuration") does not persist in all cases. For example, if I delete any shared drive from the wine config, they show back up automatically the next time the bottle is accessed.

Has anyone got any tips on locking down this awful default behavior?

I would prefer to being able to change this insecure default-behaviour as well. eg removing a shared drive from a bottle is not persisting for some reason it re-adds the drive at some point again: I am unable to figure out the cause for this, sometimes the drive re-appears after restarting Crossover, sometimes is does not.
Again, from a security-standpoint I would much prefer being able to control what is effectively mounted into a virtual machine.

Ehh Wine Is Not Emulator, and why would you trust a native game binary to not mess with your critical system files or read your encrypted volumes? Hint: some anti-cheat solutions do scan your files and upload telemetry.

The answer is simple: the System deals with this, and CX as a user-land-only program remains transparent. In addition to permissions, Sonoma enforces Access Control for all apps whether we users like it or not (old apps were not coded to deal with or even tolerate denied access. And old as they are, there won't be a fix for them). Thus even legitimate apps cannot scan for a corresponding helloworld.h of the open helloworld.c if it's not granted access to the parent directory (say ~/Documents) beforehand.

If you don't grant Crossover Removable Disk access then apps launched from it won't inherit it. If you don't grant the separate ~/Applications/Crossover/App.app said privilege, then later runs launched by that shortcut won't have it. Considering that double-clicking and dragging icons and selecting a file from macOS's Open dialogue all constitute ad-hoc permission grants, there's little resistance in limiting what Crossover's main app bundle has access to.

Well, except when explorer.exe hits a wall (say tries to peek inside Z:\ -> /) and hangs all relevant processes. Probably what 24.0.3 fixes.

I created this script to remove all symlinks (keeping the c: drive), and create a new z: drive pointing to ~/Downloads, if you don't do this you will need to copy the installer.exe into the bottle. This shouldn't cause any problems, I just know that creating and copying the bottle will rebuild these symlinks.

nyakori wrote:

I created this script to remove all symlinks (keeping the c: drive), and create a new z: drive pointing to ~/Downloads, if you don't do this you will need to copy the installer.exe into the bottle. This shouldn't cause any problems, I just know that creating and copying the bottle will rebuild these symlinks.

This script has been confirmed to cause licenses to not be read when executed on CrossOver Preview. This requires at least a drive pointing to /, and may cause other problems in the official version of CrossOver as well. After testing with explorer.exe, access to user documents, desktop, downloads and other folders will be handled by macOS Privacy & Security settings. Public folders can be read and written, but are usually located in /Users/*. Symbolic links pointing to Documents, Desktop, Downloads, etc. have been replaced with folders, and programs should not be able to read more private files. This should be enough for privacy protection.

PS: The script will be updated later, please check the changes in GitHub Gist.