Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 17 Dec 2016 19:59:49 +0100
From:      Alexander Leidinger <Alexander@leidinger.net>
To:        SK <fbstable@cps-intl.org>
Cc:        freebsd-jail <freebsd-jail@freebsd.org>
Subject:   Re: ZFS and Jail :: nullfs mount :: nothing visible from host :: solved [partial]
Message-ID:  <20161217195949.Horde.PTQ3AH5YpaT79dVSxM5UvNr@webmail.leidinger.net>
In-Reply-To: <d606c9ee-f5f6-55c5-0c99-01fd47a4a378@cps-intl.org>
References:  <aa078173-e9f1-3f09-41d4-6613014b1119@cps-intl.org> <584986D0.3040109@quip.cz> <2b6346f8-ed02-0e6d-bd89-106098e7eb2d@cps-intl.org> <58499446.3050403@quip.cz> <eed9efad-9bac-9d36-b75e-c41f9ea72a8b@cps-intl.org> <5849C5BF.7020005@quip.cz> <fb56ab21-026b-408d-f712-ed7479e1f269@cps-intl.org> <584A9179.9060508@quip.cz> <b53fba06-bb7d-06d8-34a4-4677805fb175@cps-intl.org> <584A9D89.4040003@quip.cz> <3851c5d9-7646-b670-357e-ae937fcc7e8f@cps-intl.org> <584AB345.4080307@quip.cz> <33473585-3cb9-10d3-acf9-0a917c5a0079@cps-intl.org> <20161216141540.Horde.zfu3fokeVx7FuFkk7_s-nbW@webmail.leidinger.net> <d606c9ee-f5f6-55c5-0c99-01fd47a4a378@cps-intl.org>

next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format and has been PGP signed.

--=_K9AONlVuvw9Zy4MTTLpJPDH
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoting SK <fbstable@cps-intl.org> (from Fri, 16 Dec 2016 14:02:20 +0000):

> On 16/12/2016 13:15, Alexander Leidinger wrote:

>> For one of the filesystems I have set "zfs allow" permissions, but=20=20
>>=20just that a specific user in the jail can do something on those FS=20=
=20
>>=20without the need to switch to root. So as long as you try to do a=20=
=20
>>=20zfs create/snapshot with an user with UID 0 inside the jail, the=20=20
>>=20"zfs allow" part doesn't come into play.
>>
>> So assume space/jails/xyz.leidinger.net/ to be the dataset which=20=20
>>=20contains the root of the jail but is not attached/attributed to the=20=
=20
>>=20jail itself. space/jails/xyz.leidinger.net/data with=20=20
>>=20mountpoint=3Dnone to be attributed ("zfs jail xyz=20=20
>>=20space/jails/xyz.leidinger.net/data") to the jail (similar to the=20=20
>>=20"space/something" in the ezjail config above, I have some=20=20
>>=20iocage-managed jails were this works). In this case you should be=20=
=20
>>=20able to do from inside the jail "zfs create -o mpuntpoint=3D/mnt=20=20
>>=20space/jails/xyz.leidinger.net/data/test".
>>
> hmmm, I'm slightly confused at this point. Let me see if I can=20=20
>=20clarify that in my brain
>
> If I understand you correctly, what you are suggesting is, the=20=20
>=20dataset used by the jail itself for its root/base cannot be "worked=20=
=20
>=20on" from within the jail, but if I define a different dataset (under=20=
=20
>=20the same branch below the jail dataset), and attribute it to the=20=20
>=20jail, then I can manipulate that "other" dataset. Could you please=20=
=20
>=20confirm if I understood it correctly?

Correct.

You need the data in the root of the jail to boot, if you then=20=20
attribute=20this dataset to the jail, it will vanish until "zfs mount=20=20
-a"=20is run (rc script inside the jail). As it will vanish during the=20=
=20
boot=20of the jail (if added automatically), the rc script to mount all=20=
=20
datasets=20can not be found.

>>> And now to everyone, I am still confused about zfs set jailed=3Don.=20=
=20
>>>=20As I mentioned on my previous emails, as soon as I do that, the=20=20
>>>=20dataset vanishes from the host system (as I understand, that is=20=20
>>>=20expected behaviour). Then the jail fails as it is unable to mount=20=
=20
>>>=20/dev, /proc
>>
>> From the zfs man page:
>> ---snip---
>>     After a dataset is attached to a jail and the jailed property is set=
, a
>>     jailed file system cannot be mounted outside the jail, since the jai=
l
>>     administrator might have set the mount point to an unacceptable valu=
e.
>> ---snip---
>>
>> So yes, it is expected that it "vanishes", but it should be visible=20=
=20
>>=20from the parent host at the place inside the jail FS subtree were=20=
=20
>>=20it is mounted there (after setting the mountpoint of the dataset).
>>
> I think what you are trying to tell here is, unless and until that=20=20
>=20"vanished" dataset is put to use (mounted) from inside the jail, it=20=
=20
>=20will remain vanished/unusable from the host itself; however, once=20=20
>=20that dataset is put to use, the host system should be able to "see"=20=
=20
>=20and maybe even work on that dataset. Could you please confirm if I=20=
=20
>=20understood you correctly?

Correct.

A sub-dataset which is not needed to boot, or a dataset not within the=20=
=20
subtree=20of the jail (and not needed to boot) can be used.

Bye,
Alexander.

--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF

--=_K9AONlVuvw9Zy4MTTLpJPDH
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----

iQIcBAABAgAGBQJYVYskAAoJEKrxQhqFIICErHwP/13/s8PzZMP0lLFi4hh4SjxA
FHNVhEzdapZMtYMe62vz2W3UkSxZTRsGnehnYINvh6KOd0MZ6lKAfar8dIP20qrm
eIsj4qh9sWcEpkSYOpM16uEdNJ1wIdniKhd4OmR/nyMshdHHVXVtdRIDVVA6OFav
lscK45Evixfb5PKhReR1zpqa747jB8v8e6vbzmg8Or+I01gugb9Wa1j2g7BZhi+N
wOzIYa2Y5jn20xcCtuWG3EMbKXQATyhhfPvz/fKnedLFag4I4uoMtnCOI1iREDMk
FcZMs5YKXHvQRclfMKh+zTpc+Gszf8PQsHwNlU5veTmI7jsWP6p21HxTOjL/CbNy
SpIn+YQkqfCvVRGEogKHinl/ltUQnV7nT0g2kl1Od8eSHxCtJQUf0sOy0/PSBf2q
50sxX0FMWUazRNWf00BhIHcxHbj4PmW0lgh014eptKNoB2o0DF23bhD6DigE2zaC
TU0rnb3cDKeUIssu3gMrx0p3JlX1Ob9eyxVPWkSJwixlgIpazwAQRBFq6O8VuftW
gSDsNE7XUw3YS59kCiKMu/Sswr3pshy3pDpIONQp2j4//uFckVDMgQsbHdghCf68
oLxcoulpl4iPEBR5l0IkvSKWUoE/CRTSRRvr1O2X7PYW552NRMdWAJbiWdfG+lTk
JrPpii4sGtmpFoSjh5e4
=eVue
-----END PGP SIGNATURE-----

--=_K9AONlVuvw9Zy4MTTLpJPDH--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161217195949.Horde.PTQ3AH5YpaT79dVSxM5UvNr>