On 2015-11-24 03:00, Sergey Zakharchenko wrote:
I doubt this is an issue at all, but how some of the information hiding in jails work seemed a bit illogical. FreeBSD seems to be trying to hide nullfs mounts inside jails from the jailed proceses, but it isn't very good or consistent at it. For example: (inside the jail, which has a nullfs mount /path/outside/of/jail -> /path/inside/jail/to/nullfs/mount): # df Filesystem 512-blocks Used Avail Capacity Mounted on whatever/is/jails/root/dev ... ... ... ...% / OK, I can understand this (no nullfs mounts show up), but I don't get the following: # df /path/inside/jail/to/nullfs/mount/and/deeper Filesystem 512-blocks Used Avail Capacity Mounted on /path/outside/of/jail ... ... ... ...% [restricted] Why would you hide the target of the mount point (which I supposedly know, since I need it to issue the df command) , but expose the source (/path/outside/of/jail)? Shouldn't it be the other way around?
The statfs restriction on jails don't really work well with statfs(2), because of the issue you mention. In an earlier incarnation (before my time), it was named after getfsstat(2), where it makes more sense: it will simply leave the restricted filesystem out of the list. I suppose handing "[restricted]" off to statfs(2) is better than giving the answer for a different filesystem, or denying that a mount point exists at all. As for exposing the nullfs source, it's because the jail system is agnostic to nullfs. It merely passes along the f_mntfromname as given. - Jamie _______________________________________________ freebsd-jail@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
