SK wrote on 2016/12/09 11:12:
zfs list is good start. I never used zfs from within jail so I cannot
comment on permission denied. I don't know what more must be done.
I'm not sure which list you are referring to. I could not find any zfs
list in FreeBSD mailing list lists
I mean your command "zfs list", because normally "zfs list" inside jail
print: "no datasets available" :)
But, what I would really like to have
a) ONLY the relevant datasets for a jail are visible and can be
manipulated from within the jail. I do not mind if they are visible from
host (in fact, I might prefer that -- not manipulate, just see and maybe
take snapshot of what is there -- helps in centralizing backups). But
the Jails /must not/ see each others' datasets
zfs create gT/JailS/testJail
zfs set jailed=on gT/JailS/testJail << Did you set this property?
# (populate & start jail)
zfs jail testJail gT/JailS/testJail
b) if that is not achievable, maybe not allow the jails to see the
complete dataset hierarchy -- just make them feel that they are where
they are in a root, but still be able to create datasets that would
magically show up in the respective jails. This way, the total control
is from the host itself, where no one has access to, but the datasets
are restricted to different jails.
What is visible is controlled by enforce_statfs values. If you create
/tank/jail/alpha and set this path to you first jail no other jail will
know about it.
Now, for the sysctl values, here they come
sysctls seem OK, I am out of ideas now. maybe I will have time next week
to try this on my test setup.
Miroslav Lachman
_______________________________________________
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"
