Date: Wed, 09 Jan 2019 11:52:12 +0000 From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: "Alexander Leidinger" <Alexander@Leidinger.net> Cc: "Michael W. Lucas" <mwlucas@michaelwlucas.com>, jail@freebsd.org Subject: Re: enforce_statfs showing leading path Message-ID: <CC2137F0-755C-442B-B421-5C1032D591FF@lists.zabbadoz.net> In-Reply-To: <16831fcb2d8.27fa.fa4b1493b064008fe79f0f905b8e5741@Leidinger.net> References: <20190108190347.GA89234@mail.michaelwlucas.com> <16831fcb2d8.27fa.fa4b1493b064008fe79f0f905b8e5741@Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9 Jan 2019, at 9:42, Alexander Leidinger via freebsd-jail wrote:
Hi,
I’ll be a bit verbose also for mwlucas.
> You see the dataset name of zfs without stripping. The mount point is
> correctly stripped. I don't remember how this looks on ufs.
/dev/ada0p19 on / (ufs, local, journaled soft-updates)
/local/data/www1/users/johndoe on /usr/home/johndoe/www1 (nullfs, local)
The “device” is also visible there, as well as file system type and
specific options.
I also added a nullfs example. For that the mount point is properly
treated and lost the /local/jails/whatever/ prefix with enforce_statfs=1
but the “device” side is just as visible in full as it is for a any
other real device.
> With jailed datasets we would need more than just some code to remove
> parts of the name.
>
> So it's a doc bug (clarity about mount points and dataset names) and a
> zfs issue.
Well, no it’s not a zfs specific issue. And the docs talk about mount
points not about the “device” (or dataset in zfs parlance).
If anything for clarity one could add a sentence to the jail(8) page
saying that the “device” part of the mount output is not being
restricted or altered.
One of the reasons for enforce_statfs certainly was to limit the amount
of information; that also has the side-effect of scripts parsing the
mount (mount points) output actually finding the paths they might be
looking for.
The df command output might make some of this all a bit more clear.
> Am 8. Januar 2019 8:34:17 nachm. schrieb "Michael W. Lucas"
> <mwlucas@michaelwlucas.com>:
>
>> Hi,
>>
>> I'm experimenting with enforce_statfs for the jails book, and have
>> hit
>> an inconsistency. Not sure if the bug should go to src or doc.
>> Running
>> last week's -current.
>>
>> According to jail(8):
>>
>> When set to 1, only mount points below the jail's chroot
>> directory are visible. In addition to that, the path to
>> the
>> jail's chroot directory is removed from the front of
>> their path‐
>> names.
>>
>> Seems pretty clear that I shouldn't see anything other than
>>
>> # jls -h name enforce_statfs
>> ...
>> ioc-www1 1
>>
>> So, as I read it, the jail's chroot directory should be stripped down
>> to /. But inside the jail:
>>
>> root@www1:~ # mount
>> iocage/iocage/jails/www1/root on / (zfs, local, nfsv4acls)
^^^^ it is stripped down to /
>> devfs on /dev (devfs, local, multilabel)
>> fdescfs on /dev/fd (fdescfs)
>>
>> I see the jail's chroot directory.
>>
>> This seems to contradict the man page, unless I'm misunderstanding.
>>
>> Is this a software bug? A ZFS thing? A doc bug? Or am I just an
>> idiot?
>>
>> Also, should this path be stripped when enforce_statfs is set to 1
>> *or
>> above*? Or is this strictly when set to 1? If I'm filing a bug, it
>> might as well be complete...
>>
>> Thanks,
>> ==ml
>>
>> --
>> Michael W. Lucas https://mwl.io/
>> author of: Absolute OpenBSD, SSH Mastery, git commit murder,
>> Immortal Clay, PGP & GPG, Absolute FreeBSD, etc, etc, etc...
>>
>>
>>
>> ----------
>> _______________________________________________
>> freebsd-jail@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-jail
>> To unsubscribe, send any mail to
>> "freebsd-jail-unsubscribe@freebsd.org"
>
>
>
> _______________________________________________
> freebsd-jail@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-jail
> To unsubscribe, send any mail to
> "freebsd-jail-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CC2137F0-755C-442B-B421-5C1032D591FF>