Feature request: ability to modify system files without touching $PREFIX
MagicalTux opened this issue · comments
Expected Result
When running tools like xcode-select --install system files needs to be modified. This should happen in the user's home (via overlayfs or similar).
Actual Result
Darling attempts to write to $PREFIX, which in my case is a read only filesystem for security reasons.
Darling [~]$ sudo xcode-select --install
You are about to download and install Apple Command Line Tools covered by the following license:
https://www.apple.com/legal/sla/docs/xcode.pdf
Do you agree with the terms of the license? (y/n) y
Downloading packages...
Downloading DevSDK_OSX1012.pkg...
Installing...
installer: Installing package com.apple.pkg.DevSDK_OSX1012 version 9.2.0.0.1.1510905681 (261534 KB)
installer: Extracting files
Cannot create symlink /./System/Library/Frameworks/AGL.framework/Headers: Permission denied
Installation failed with exit code 1
Similar issue from someone else also found: #1222
Steps To Reproduce
- Run
xcode-select --installas regular user - Accept license
System Information
What system are you using?
| Software | Version |
|---|---|
| Linux Kernel | 6.5.8 |
| Darling | 47c204a |
Actually it seems there is already an overlay mount, but that doesn't explain why this operation fails.
overlay /tmp/darling overlay rw,relatime,lowerdir=/pkg/main/app-emulation.darling.core.0.1.20231004.linux.amd64/libexec/darling,upperdir=/tmp/darling,workdir=/tmp/darling.workdir,index=off 0 0
I'm guessing "sudo" in darling doesn't actually do anything, which results into the folder to not be write-able by the current user, and the write just fails because of that.
Note: running darling as root makes xcode-install work, it's possible to use the same DPREFIX afterward as a normal user
This is a known bug that's difficult to reproduce: sometimes the prefix will be created with incorrect permissions, leading to errors when trying to modify it. You can try shutting down Darling (darling shutdown), deleting the prefix (rm -rf ~/.darling), and then running Darling again to recreate the prefix.
This appears to be the same as #1166; closing in favor of that older issue and re-posting my reply there.
@facekapow Actually this is different than #1166 since that one is about writing to $HOME/Library while the issue here is about /Library which should be writable when with sudo I guess?
This can be solved however by running darling as root, but that's likely not the best idea.