Matthew Ahrens wrote: > George Wilson wrote: >> Darren J Moffat wrote: >>> Is it possible to have dataset properties that are managed using the >>> dsl_prop_set() / dsl_prop_get() interfaces that aren't made >>> available via zfs(1), in fact I probably don't want them in userland >>> at all. >>> >> You can set the pd_visible field in the zfs_prop_table[] to indicate >> that the property should be not be visible. > > >>> Specifically I'm wondering if I can use dsl_prop_set() to store the >>> wrapped encryption key for a dataset. I don't want that wrapped key >>> being available via zfs(1) as a property, or available to any >>> unprivileged userland application via libzfs. >>> >>> >>> >> You can set the property attribute to be readonly and invisible which >> would keep anybody from touching via the zfs(1) command. > > Right, but Darren wants it to exist in userland at all (eg, for no > ioctl to mention its existence). I believe that readonly/invisible > properties are still in the nvlist that we pass up to userland. I > think you'd have to add a special case to dsl_prop_get_all() for it to > not be passed up to userland. > > --matt Matt,
Thanks for bringing up that point. I had made the assumption that the requirement for kernel only was to prevent zfs(1) from displaying it or setting it. Thanks, George
