On macOS, Process::FindSystemBinary() searched /usr/local/bin first, so a
user-writable /usr/local/bin (the default on Homebrew installs) could
shadow system tools.
This resolver is also used to locate privileged binaries during privilege
elevation: CoreService.cpp resolves "sudo" (and "true") through it both
when probing for an active sudo session and when launching the elevated
helper, and the admin password is written to that sudo process's stdin.
On a typical Homebrew install /usr/local is owned by the (non-root) user,
so a planted /usr/local/bin/sudo would be selected ahead of /usr/bin/sudo
and could capture the admin password, leading to privilege escalation.
Reorder the macOS list to {/usr/bin, /bin, /usr/sbin, /sbin,
/usr/local/bin} so system locations always win. The binaries actually
resolved through this function on macOS (sudo, true, fsck, the terminal
helper used for filesystem checks and its dependencies, and non-APFS
formatters) live in system directories, so /usr/local/bin is kept only as
a last-resort fallback and can no longer shadow them. (diskutil, hdiutil
and newfs_apfs are invoked via absolute paths and were never affected.)
Co-authored-by: Damian Rickard <damian@rickard.us>
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>