Unable to modify directory /var/db/MobileIdentityData

[invalidunit]

Unable to modify directory /var/db/MobileIdentityData

[opa334]

Probably due to some entitlement missing in the bootstrap / in Filza

[invalidunit]

I think it may not be a matter of permissions. In iOS 14 (Taurine), the Filza installed by Trollstore also does not have permission to edit any files inside. However, after jailbreaking and continuing to use the Filza installed by Trollstore, it can be found that the files inside can be edited. I think there may be other places that need to be patch.

[invalidunit]

I think it may not be a matter of permissions. In iOS 14 (Taurine), the Filza installed by Trollstore also does not have permission to edit any files inside. However, after jailbreaking and continuing to use the Filza installed by Trollstore, it can be found that the files inside can be edited. I think there may be other places that need to be patch.

The same thing happens with Checkra1n and Palera1n.

[Cryptiiiic]

@invalidunit This isn't a dopamine issue, nor palera1n, sandbox protects many directories, the process needs special entitlements to read/write to certain directories.

[tuxudo]

I'm encountering this as well, but with /var/mobile/Containers/Data/ over ssh/sftp. I think it's an entitlement or sandboxing of sshd issue

[tuxudo]

Update: I fixed this by giving more entitlements to sshd and sftp-server, copied entitlements from TrollStore Filza

[invalidunit]

@invalidunit This isn't a dopamine issue, nor palera1n, sandbox protects many directories, the process needs special entitlements to read/write to certain directories.

No, what I meant was that both checkra1n and palera1n do not have this issue and can read and write to this directory normally.
Additionally, in tests conducted on a taurine device, using filza installed through trollstore while in a jailbroken state, I was able to open this folder and read and write to it normally. However, after rebooting without restoring rootfs and continuing to use filza installed through trollstore, attempts to read and write to the path resulted in the inability to add, delete, or modify files inside it.
Therefore, I still believe that this is not an issue of missing special permissions, but rather one that requires the jailbreak to handle this situation.

[opa334]

Previous jailbreaks injected entitlements using detached signatures, Dopamine does not do that, therefore this has to be fixed by resigning the binaries with them.

[invalidunit]

Previous jailbreaks injected entitlements using detached signatures, Dopamine does not do that, therefore this has to be fixed by resigning the binaries with them.

Could you please inform me of what permissions should be granted for binary files to be signed when reading and writing to this directory?

[opa334]

Previous jailbreaks injected entitlements using detached signatures, Dopamine does not do that, therefore this has to be fixed by resigning the binaries with them.

Could you please inform me of what permissions should be granted for binary files to be signed when reading and writing to this directory?

I have no idea, you need to figure this out by yourself

[Cryptiiiic]

Could you please inform me of what permissions should be granted for binary files to be signed when reading and writing to this directory?

@invalidunit I can tell you the standard.
Directories that will contain executables and dylibs should be 0755, directories that won’t be containing executables and dylibs should be 0644. Executables themselves should be 0755. Dylibs should always be 0644. Everything should be owned root:wheel (0:0) except /var/jb/tmp and /var/jb/var/mobile those should be 501:501 owned.

dylibs should not contain any entitlements. For sandbox entitlements I recommend looking at containermanagerd for reference.

[Lessica]

<key>com.apple.private.security.container-manager</key>
<true/>

This entitlement is required for all binaries accessing /var/mobile/Containers/Data.

Consider update all base packages, or add a hook to dpkg and use ldid to re-sign the related binaries after installation.

[opa334]

Look I'm certainly not going to hook dpkg. The way to solve this is either to convince Procursus to push updates or implement detached signatures like previous jailbreaks (a lot of work).

[opa334]

Issue should be raised to Procursus instead.

[invalidunit]

it was found that the permission could be used to write to the directory

<key>com.apple.rootless.install.heritable</key>
<true/>