sockstat: chdir to jail path before attaching to vnet jail

[freqlabs]

Summary

jail_attach(2) does not change the working directory, so it must be done separately.

[mjg]

This is a bug in jail significant enough to add a syscall doing the trick.

[jamie]

Or is it significant enough to just fix a syscall? There's no good reason to attach to a jail while not being inside its directory structure, and I don't know of any program that depends on such a misfeature.

[freqlabs]

Something like this?

diff --git a/sys/kern/kern_jail.c b/sys/kern/kern_jail.c
index afe9afb50471..91e411fb023d 100644
--- a/sys/kern/kern_jail.c
+++ b/sys/kern/kern_jail.c
@@ -2406,6 +2406,7 @@ do_jail_attach(struct thread *td, struct prison *pr)
 		goto e_unlock;
 #endif
 	VOP_UNLOCK(pr->pr_root);
+	pwd_chdir(td, pr->pr_root);
 	if ((error = pwd_chroot(td, pr->pr_root)))
 		goto e_revert_osd;
 

[jamie]

Yes, I imagine that's all it needs.

On a related note, I'm not really happy with chroot_allow_open_directories applying to jail_attach. That one's harder to fix though, as it would take an API change to pwd_chroot or something like that.

[mjg]

A proper fix would avoid entering a jail to begin with, but that may be too much work right now.

I'm arguing for a new syscall because there is probably way more than chdir to add and avoiding changes to jail_attach semantics avoids a case where breakage was detected and it is unclear what to do.

Tl;dr bare minimum this should add jail_attach2(int jid, int flags) arg with flags being hardwired to 0 and meaning switch as much as possible (including chdir).

[freqlabs]

No longer necessary.