The hdiutil `-plist` output used for mount/dismount device discovery
(MountAuxVolumeImage and UpdateMountedVolumeInfo) was parsed with a
hand-rolled string scanner that assumed the value always follows the
requested key and that <key>/<string> pairs appear in a fixed order.
Replace it with the CoreFoundation property-list API
(CFPropertyListCreateWithData + dictionary/array navigation), which is
correct by construction and robust to hdiutil output ordering/variation.
An RAII helper (CFHolder) ensures CFRelease on every path.
Behavior is preserved: prefer the system-entity that carries a
mount-point, otherwise fall back to the first dev-entry, and match disk
images by normalized image-path. CoreFoundation is already linked on
macOS (via Cocoa), so no build changes are needed.
Verified end-to-end on Apple Silicon: mounting parses `hdiutil attach`
output and dismount parses `hdiutil info` output correctly.
Co-authored-by: Damian Rickard <damian@rickard.us>
* Honor --no-size-check when creating file containers via the CLI
The text-mode volume creation path clamps the maximum allowed volume
size to the available free disk space and never consults
ArgDisableFileSizeCheck, so the documented --no-size-check switch has no
effect when creating a file-hosted container with `--text --create`.
The flag is honored by the GUI wizard (Forms/VolumeSizeWizardPage.cpp)
but was missing from the text UI, making it impossible to create a
(sparse) container larger than the current free space from the command
line -- even though such a container is perfectly valid on filesystems
with sparse-file support (e.g. APFS, ext4, NTFS) and is exactly what the
flag exists to allow.
Skip the free-space clamp when --no-size-check is set, mirroring the GUI
behavior.
* Fix max volume size handling with no-size-check
Keep the max size sentinel and interactive max choice bounded by available disk space even when --no-size-check allows explicit sparse container sizes beyond the current free space.
---------
Co-authored-by: Damian Rickard <damian@rickard.us>
Co-authored-by: Mounir IDRASSI <mounir.idrassi@amcrypto.jp>
The privileged CoreService handler for SetFileOwnerRequest passed the
client-supplied path straight to chown() as root with no validation --
unlike the adjacent APFS formatter handler, which strictly validates its
device argument. Every legitimate macOS caller of the elevated
SetFileOwner targets a real disk device node (/dev/[r]diskN[sM]), so a
crafted IPC request, or a symlink planted at the target, could otherwise
make the root process change ownership of an arbitrary path.
Validate the target service-side: require the strict device-path form
already used by the formatter, and lstat() it to confirm a block or
character device (rejecting symlinks rather than following them) before
the chown.
Co-authored-by: Damian Rickard <damian@rickard.us>
damianrickardandDamian Rickard
