This in a nutshell is why the incompatibility is significant: systems may be running more than just a docker workload requiring these security features, so saying "it's secured in the normal docker case anyway", even if true, doesn't really help to solve the problem.
The preferred suggested fix was "mknod and chmod during image builds to be executed from outside of any chroot". In siding with docker in not considering this fix, you seem to be alluding to last year's http://seclists.org/fulldisclosure/2016/Oct/96 vulnerability, now fixed. A more intelligent fix would be 'require a modern/secure archive extraction tool'.
The second fallback was "Docker could check for the existence of /proc/sys/kernel/grsecurity/chroot_deny_chmod and /proc/sys/kernel/grsecurity/chroot_deny_mknod and, if present, ensure the values of both are 0."
AFAIK nothing happened.
I don't think you read my comment properly. I'm saying that the security feature doesn't apply to Docker, but disabling it would be bad because it will affect other applications on the system.
> The preferred suggested fix was "mknod and chmod during image builds to be executed from outside of any chroot".
Which as I said, wouldn't be a good idea because of how chrootarchive works. In short it would lead to path traversal attacks, as with the issue you mentioned. The fix was to properly chroot things IIRC.
> A more intelligent fix would be 'require a modern/secure archive extraction tool'.
I agree. Are you willing to write a patch for it (or add patches to GNU tar?), because I'm afraid I don't have the time to do it at the moment (and I don't contribute to Docker that much these days).
> The second fallback was [...]
Which would be a bad thing to do because it would purposely disable security features that will affect other applications.
> Another security area I looked at was docker grsec incompatibilities, eg. https://github.com/docker/docker/issues/20303 though didn't get closure despite suggesting what IMHO seems a decent fix. Meh.
I don't like Docker's chrootarchive any more than the next person, but your fix is not trivial (unless the fix you're referring to was to disable the security features). Part of the point of chrootarchive is that it protects against a malicious archive from modifying the host filesystem through dodgy paths -- something that using a chroot prevents. Otherwise chrootarchive would have to implement all of the chroot path handling code the kernel normally deals with (which is not good fun, take it from me).
The security issues that grsec is trying to protect users from do not apply to chrootarchive because (in principle) the binary being run in chrootarchive is safe (it is `tar -x` so shouldn't actually be trying to access or otherwise mess with disks for example).