site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Jul 26, 2007, at 12:48 AM, Standard Azi wrote: -Shawn _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... If there was KPI exposed for reading extended attributes, then yes. Unfortunately there is no such KPI exposed, and so you're in a position where you will have to ship your operation out to user space. As I've already mentioned in another reply related to this message, the main concern with userspace is *performance*. Hooking KAUTH_SCOPE_FILEOP is already a performance issue per se. Now imagine communicating with userland for each open() call, and acting differently in only 20-30% of cases. That's why the application design at the moment communicates with userland only when we find the specific attribute set. Sometimes you have to give a higher priority to performance omitting clever design. (and, don't think I like that). I assure you Michael is well aware of the performance implications... his was just pointing out what you have to work with. What you have to work with isn't going to change without Apple deciding to enhance their KPI and it won't magically show up on 10.4 or earlier (possibly not 10.5 at this point either). So it comes down to you needing to decide on following the rules or breaking them with the later becoming a potential maintenance nightmare with your product breaking with security or software updates (assuming you can find a solution, Apple folks aren't likely to help you break the rules). This email sent to site_archiver@lists.apple.com