https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285782
--- Comment #11 from [email protected] --- The problem isn't just allowing such rename()s, but that afterward moved directory's ".." entry can be used esacape the jail. I consider the "don't move directories" answer bullshit, because **any** unjailed user can help a jailed **root** user escape its root path while keeping root privileges on filesystem operations. So you're effectively telling users all host users have to be treated as equivalent to passwordless sudo to root unless the issue is mitigated even if I understand that always scanning if the jail root vnode can be found along the ".." chain of a jailed process when traversing through ".." (and fchdir() + any *at() syscalls) is ugly and would introduce painful overhead. No user who doesn't happen to also be a kernel developer who has worked on the jail subsystem can be expected to be able infer what is safe from the NOTES section and even if the to paragraphs are rewritten such a giant footgun doesn't belong hidden in at the very end in a NOTES section of all places. Such a dangerous glaring limitations deserves its on SECURITY section and a forward reference to that in the first paragraph of the DESCRIPTION. If that feels wrong because it would scare users away maybe the problem should to be a fixed instead. Maybe having a nullfs-light pseudo-fs (jailfs?) that only rewrites its root directory would be less fragile than making each filesystem jail aware enough to handle this case? In the next .0 release jail(4) could then be changed to always mount this filesystem unless the root directory is already a mountpoint? -- You are receiving this mail because: You are the assignee for the bug.
