Hello list,
Recently we started playing around with booting on ZFS instead of HFS.
I do not think that will win me any sympathizers with people, but it is
certainly a fun experiment, and a great way to check compatibility with HFS.
So generally I have ignored everything to do with the XNU compile define
"MACF", the security layer and Sandbox.kext, since it has "just worked" in
the past. We've both been happy. However, booting ZFS has lead me down a
dark hole.
It all started with that, once you are booted, Fonts do not appear to work
correctly. With messages about LastResort font being unavailable. But
that's just the tip of the iceberg.
Load up Font Book, and click on "validate font" will return with "system
validation failed". At first I thought maybe ZFS returns some query
different to HFS, but it appears to be related to security checks.
dtracing "FontValidator" (on ZFS boot) will show;
2980/0x6fc82: getattrlist("/Users\0", 0x7FFF592A2490, 0x7FFF592A22B0,
0x128 0x5) <commonattr 0x6040A, volattr 0x0, dirattr 0x4, fileattr 0x0,
forkattr 0x0> = -1 Err#1
ATTR_CMN_DEVID,ATTR_CMN_OBJTYPE,ATTR_CMN_MODTIME,ATTR_CMN_ACCESSMASK,ATTR_CMN_FLAGS,
ATTR_DIR_MOUNTSTATUS,
which is curious. Looking at sources for XNU, the first test it does is to
call mac_vnode_check_getattrlist(). Which dtrace confirms;
0 148745 mac_vnode_check_getattrlist:return FontValidator 1
Why is it failing something so trivial as a metadata lookup on /Users? The
function is not passed much information;
mac_vnode_check_getattrlist(vfs_context_t ctx, struct vnode *vp,
struct attrlist *alist);
And the hook for it appears to be in Sandbox.kext. Not much information on
this "blackbox", and that is probably how it should be. The call itself
doesn't do much more than sb_evaluate, derive_vnode, and getpath.
However, it is interesting to note that validating a font on ZFS (boot HFS)
will work fine. So it is something specific about booting ZFS, not the
filesystem compatibility itself.
vfs_mountroot() does the same for HFS as ZFS, calls mountroot (or rather,
VFS_MOUNT if vfc_mountroot is NULL), then calls VFS_ROOT() to setup calls
to call vnode_label(); which in turn calls mac_mount_label_init()
mac_mount_label_associate().
There are no special MACF calls in the HFS sources, and NFS simply calls
mac_mount_label_init() mac_mount_label_associate() directly.
In theory, it should be initialized the same regardless of what format is
booting..
and yet I have angered Sandbox.kext somehow.
Is there some way to get more information out of
mac_vnode_check_getattrlist()? Debug logs? That vtrace call?
At the moment it is a vast problem due to the unknown nature. I'm not
entirely sure what vnode "labels" are for, or is it something wrong in the
context struct (opaque to us) or the vnode names we set? Or a hundred other
things...
Unfortunately, it seems setting security.mac.vnode_enforce = 0 no longer
disables vnode checking, so I can't confirm that this is the problem.
(Since SECURITY_MAC_CHECK_ENFORCE was added). But I assume it is since
mac_vnode_check_getattrlist() is returning failure.
I do not know if anyone has tried booting something else in the past, so I
might be alone at the front line, but perhaps there is knowledge on how to
please the security layer out there?
Lund
ps. Ever since HFS went into a kext, and all the hfs_vnop_* calls went
static, I can no longer dtrace HFS calls. (For comparison). Is this
intentional? Since the sources are released for HFS I hope maybe dtrace
hooks could be brought back...
--
Jorgen Lundman | <lund...@lundman.net>
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 (Filesystem-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/filesystem-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
