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. 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. -- Darren J Moffat
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. Thanks, George
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.Cool!>> 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.Fantastic. If I do that can I inside the zfs kernel module make it readwrite and change its value later ? -- Darren J Moffat
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
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. > > --mattMatt, 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
Darren J Moffat 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. >> > > Cool! > > >>> 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. >> > > Fantastic. > > If I do that can I inside the zfs kernel module make it readwrite and > change its value later ? > >Yes. - George -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-code/attachments/20070703/ad498359/attachment.html>
Matthew Ahrens wrote:>> 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.Yep just been looking at the code and spotted that. Rather than adding a special case for my options it is probably better to extend the table with a new boolean (pd_ioctl) which I''d set to false, right ? -- Darren J Moffat