ZFS and Jail :: nullfs mount :: nothing visible from host

[SK]

Thanks Miroslav, I get the picture now. Please see my reply inline
>>> 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" :)
>
OK, considering that I have the setup as I explained before, and have 
run zfs jail testJail gT/JailS/testJail, I can see the complete dataset 
along with the ones that are NOT part of the jail. So, whatever dataset 
the host can see, I can see from inside the jail. However, I cannot do 
anything with the dataset from inside the jail.

>
>> 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?
Now this is an interesting bit. I tried this, and as soon as I ran the 
command, the dataset vanished :P

Not only that, I could not run jail any more. Given that gT/JailS is 
mounted on /JailS and the path parameter in jail.conf is 
/JailS/testJail, I am not surprised that the jail did not run (it 
initially complained about not being able to mount /dev, as it cannot 
find /JailS/testJail/dev)

As a workaround, I removed mount.devfs, mount.procfs (that complained 
too), mount.fdesc (complained too), and then the jail ran

But now that I do not have devfs, I could not do anything with zfs -- I 
could not even see them. So, manipulation from within the jail or 
outside the jail was no longer possible.

>
> # (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.
This I believe is where I am stuck at the moment. How do you set this 
path to the jail? Apparently running zfs jail testJail gT/JailS/testJail 
did not stop the testJail from seeing gT/Data or gT/JailS/Moving -- in 
fact, they became visible after that script was run.

Any suggestion/pointers is greatly welcome.

Out of a little bit of frustration (since I was unable to find any 
proper documentation on jail.conf -- there is nothing under 
/etc/default, there is nothing on the man page -- I could not even 
figure out how to define a zfs as the root/fs for the jail!), I have 
started looking into ezjail now -- given that everyone seem to claim it 
can do what I had been unable to do through command line. If my sense 
and intelligence is well enough, I might be able to find out how it is done.

Thanks again for all your help and support, it is truly appreciated.

Have a nice weekend.
SK


>
>> 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