Re: The mystery of mac_vnode_check_getattrlist()
Re: The mystery of mac_vnode_check_getattrlist()
- Subject: Re: The mystery of mac_vnode_check_getattrlist()
- From: Jorgen Lundman <email@hidden>
- Date: Mon, 19 Dec 2016 11:54:24 +0900
- Dkim-filter: OpenDKIM Filter v2.10.3 mail.lundman.net EAFE771897
Quinn "The Eskimo!" wrote:
>> I'm not entirely sure what vnode "labels" are for …
>
> Yeah, you and me both (-: However, in this case I think it’s a red
> herring;
Hmm yes, that does appear to be the case.
>
> The fun thing about the Sandbox kext is that it actually runs a small
> Scheme interpreter to decide whether to allow something. So you can’t
I have come across the tiny scheme files, and I can see that Sandbox.kext
is running the interpreter, so presumably the input that I feed it must be
a bit off.
>
> * The item’s path, using `vn_getpath` or `vn_getpath_fsenter`
>
> * The name of the file system on which the item resides, using
> `vnode_mount ` and `vfs_name`
>
> * The mount point of that file system, using `vnode_mount` and
> `vfs_statfs`
>
> * The item’s mode, using `vnode_getattr` with `va_mode`
>
> * The item’s type, using `vnode_getattr` with `va_type`
>
> * The item’s rdev, using `vnode_getattr` with `va_type` and `va_rdev`
Thank you, I was hoping for exactly this sort of email. I will keep digging.
There have been some surprises, like that of ioctl GET_BOOT_INFO insists
that the root vnode be tagged as VT_HFS (and not VT_ZFS) for it to bother
calling us. (The comment in XNU sources suggest 'future enhancement') BUT,
that didn't make any difference, so hopefully I won't have to "lie" about
the tag.
> You may be able to trace these callbacks from the Sandbox kext to the
> kernel to see where things have gone wrong, perhaps comparing the HFS
> and ZFS cases side by side.
Unfortunately I can no longer trace the incoming HFS VNOP calls, but
perhaps I can dtrace directly on VNOP_* and just filter out the noise
(including dtrace itself sending data with VNOP_WRITE).
Thanks for your reply.
Lund
--
Jorgen Lundman | <email@hidden>
Unix Administrator | +81 (0)90-5578-8500
Shibuya-ku, Tokyo | Japan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden