On Aug 31, 2012, at 4:08 PM, Joshua Root <[email protected]> wrote: > There was another thread discussing it at the end of last year, complete > with jkh threatening to write some code as I recall. But I guess nobody > found the time yet.
I did indeed threaten this, now that you remind me, and it was sadly an empty threat. :-) I did spend a bit of time looking at it and trying to harmonize it with some of the trace code that kvv originally wrote and then updated in another unrelated package, but the two had simply diverged too much and the darwintrace inside MacPorts looked somewhat more comprehensive by comparison, so the direction of the merge ended up looking somewhat dubious. I also got distracted by the notion of creating a MAC policy (kernel module) instead since MAC has hooks for every single filesystem operation and allows one to implement tracing below the syscall layer such that it doesn't matter whether the syscalls are 32 bit, 64 bit or how the syscalls which manipulate files change or evolve over time. To be honest, that would be the architecturally superior approach given the two alternatives, but would also (as I quickly found out) be rather more difficult to do since implementing the kernel module and the hooks in macports to trigger the hooks on all of its (the subject's) file objects is kind of advanced class and MAC is not an officially supported API - it's more of an internal implementation detail of XNU. All that said, the functionality is still very cool, regardless of how it's implemented, and I hope that someone does dive on the challenge since proper enforcement and validation of what MacPorts is doing for a specific port could really provide some much needed safety belting of the process, particularly as the ports collection continues to grow. Hmmm. I'm almost inspired to check out the xnu sources again... :) - Jordan
_______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-dev
