On 19. 3. 2012 9:42, Alexander Leidinger wrote: >>> The only disclosed information I know of is whether the zfs module is >>> loaded on your system. >>> Other alternative I was thinking of would be using a new ruleset (e.g. >>> devfsrules_jail_zfs=5). >>> The disadvantage here is that users that already have defined a ruleset >>> with this number should be informed somehow. > > Well... we always have this issue. If the rulsets in defaults changes, > the user has to change his own rulesets. I have a lot of rules on my > system and there was at least one occasion where I had to handle a > change because of this. I don't remember if there was an entry in > UPDATING or not, but I don't think we should make a decission about it > based upon if an user has to renumber his rulesets or not. As the > rulesets do not need to be continous, we may want to add an advise to > the man-page(s) to start at a specifc value for the ruleset-numbers > and reserve everything below for the system. I didn't do this myself, > and I have a lot of rulesets, for me this falls within 'nice to have > but easy to handle'. > >> Btw. jail has access to sysctl(8) and this discloses a *LOT* of >> information, including if ZFS is loaded or not (existence of vfs.zfs) >> and all its settings and statistics, hardware devices, geom devices, >> network card counters and many more. Compared to this is /dev/zfs really >> a minor issue :-) > > I agree. > >> Until we limit the output of sysctl() we don't hide this information >> just by hiding /dev/zfs. > > What about not imported pools. Can I see them in jails or are they > hidden (I don't have one around to test ATM)? Until you delegate a zfs dataset to a jail, the jail does not see any pools or datasets.
If you delegate a dataset to a jail, the jail sees information about the delegated dataset, the dataset's pool, the parent datasets of this delegated dataset (=the path from pool up to the delegated dataset) and the descendant datasets, if any. We might want to continue this discussion outside of the svn-src mailing lists. -- Martin Matuska FreeBSD committer http://blog.vx.sk _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
