Ceph

Do you mean with the kernel client? See fs/ceph/xattr.c,

static bool ceph_is_valid_xattr(const char *name)
{
    return !strncmp(name, "ceph.", 5) ||
           !strncmp(name, XATTR_SECURITY_PREFIX,
            XATTR_SECURITY_PREFIX_LEN) ||
           !strncmp(name, XATTR_TRUSTED_PREFIX, XATTR_TRUSTED_PREFIX_LEN) ||
           !strncmp(name, XATTR_USER_PREFIX, XATTR_USER_PREFIX_LEN);
}

Aside from that, I don't think there should be any restrictions on allowed xattrs... which means security.* should work today?

We were specifically thinking about implementing the samba-vfs/libceph connection. I had the impression this went through client/Client.h.
When I tested with a cfuse mount, it gave me op not supported on anything but user.*.

There were other issues as well, of which this was just one.

Though for now we can test ACLs with the kernel client underlying samba with just the vfs_xattr module.

This brings up a question about how tightly we can link the kernel client and libceph/cfuse/other-clients to prevent divergence in code?
What other applications are expected to exercise the object interface or libceph?

Yes, libceph goes through the Client.

Unfortunately, the uClient and the kclient are presently not linked at all -- they implement the same communications protocol but their base components (message handling, etc) are so different that I don't think there's really not a good way to link them.

Anything not in the kernel should be built either on top of Client or libceph, though, so those will all have the same internal workings! At present we don't have a lot of libceph users -- there's a (merged) Hypertable client and an (unmerged) Hadoop client but that's all I know of. The object interface is used by everything talking to RADOS, though -- librados is build on the objecter; the MDS uses the Objecter; the Client uses the Objecter...

I'd like to implement the same code from the kernel client as mentioned above.
However, to use those macro definitions I'd need to include a kernel header file, which would create a ceph-compile dependency on kernel headers.
There doesn't seem to be any standard system headers which define these.