Jail nullfs mount information visibility [redirected from secteam@]

James Gritton jamie at freebsd.org
Tue Nov 24 14:42:01 UTC 2015


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


More information about the freebsd-jail mailing list