openzfs
expose dataset’s jail name via zfs list
Describe the feature would like to see added to OpenZFS
show name of assigned jail for a jailed dataset in ‘zfs list’ properties.
# zfs jail myjail zroot/jailed
### no way to see what this assignment was using existing commands
### what we would like
# zfs get -Ho jail zroot/jailed
myjail
### should probably return with NONE or similar, or error if dataset isn’t jailed
# zfs get -Ho jail zroot/notjailed
none
How will this feature improve OpenZFS?
allow scripts to correctly identify the full mount path for backups and other tasks
Additional context
zfs on FreeBSD allows jailing a dataset. It is mounted inside a jail aka “container” and can optionally be managed inside the container.
a common pattern is to use a script running outside the container for tasks like backups, thus denying an attacker or in-jail admin to prevent backups.
This external script needs a way to loop over jailed datasets, extract the mounted path as seen outside the jail, to backup correct paths inside the jail, for example a snapshot or just active files
zfs list -o name,jail ?
Oh, I see, you were expressing that that doesn't work right now, I thought you were stating that zfs get would do this and zfs list would not, as I don't have a FBSD machine handy to test with. Don't mind me.
I don't think this'd be too exciting to expose, but doing something meaningful with the id you get back might be more exciting...
zfs list -o name,jail?
Yes, you are correct. This does not work now, with either zfs list or zfs get.
This issue reflects something which came up in my scripting.
For example, I want to specify a list of datasets, some of which might be jailed, for use by a script.
I wanted to know which jail that dataset "belongs" to.
+1 and also wanted to add a use case: In live debugging/auditing scenarios, it is often important to find out which jail is using or has used what dataset, so as to determine whether dataset's integrity is compromised by the jail (from multilevel/compartmentalized security POV, not data corruption POV).
