TL;DR: Is it time for the rest of Debian to stop conforming to HURD's lack of maximums for path and hostname? By thispoint I think we recognize those lack of maximums as an anti-pattern for DOS prevention and other security reasons.
back in the day when I got my first HURD compatibility patch, I was excited. I had read the original HURD paper, and a lot of the ideas HURD was exploring sounded really neat. Getting rid of arbitrary limits, translators, and lots of other cool stuff. So I was delighted to accept the patch into my package and try to be part of something innovative. I will admit I was kind of disappointed that rather than working to make my package handle arbitrary hostnames, the patch simply introduced an arbitrary constant for HURD. HURD managed to explore a lot of interesting ground. Through explorations like Plan9 and HURD, things like namespaces, fuse, and other features revolutionized the Linux world, spawning important innovations in themselves like containerization. But I think that HURD's desire to remove arbitrary limits like hostname and path maximums have proven not to be winners. We ran the experiment, and I at least think the conclusion is that we'd be better off with limits. Here are some of the concerns: * Having different limits in different parts of the system can lead to security problems. On Linux, when I have something that I know is a valid path, say because it's coming from the kernel, I know it fits in PATH_MAX. I don't need to worry that some other program has a different idea of PATH_MAX and I might need to deal with bounds checking or truncation attacks. However, on HURD, it's probably not sufficient to just create a PATH_MAX or HOST_NAME_MAX buffer. I probably also need to think about what happens when something gets truncated or fails to fit into that buffer. I need to think about DOS and other potential attacks. I know I have not been diligent about reviewing the HURD compatibility patches for these sorts of issues over the years. * To some extent, there are intrinsit limits that are related. The DNS does have a maximum for a domain name, and while that's not strictly the same thing as a host name, practically speaking, we want host names to be able to fit in domain names. * The kind of dynamic memory handling required for avoiding arbitrary limits introduces significant complexity. You need to have some limit at some level to avoid resource exhaustion attacks. Having constant size structures for things like stat buffers and unix domain sockets is a lot simpler than dynamically allocating everything. Bounds checking at compile time has value. So does avoiding all dynamic allocation in critical sections of system resources. The latest version of pam is not building on hurd-i386 and hurd-amd64. One of the issues is HOST_NAME_MAX in modules/pam_xauth/pam_xauth.c. I'm sure the hurd porters would send me a patch if I asked for one. I'm sure I could come up with a patch on my own. My question though is whether that's architecturally a good idea. As a maintainer, I'm willing to accept the patch if we believe that HURD's approach actually is a good one. For a non-release architecture that I perceive as more on the way out than on the way in, I'm not interested in accepting a patch if we think the architectural approach is an anti-pattern. Yes, that does put the hurd maintainers in an awkward position: pam is transitively essential. * They could agree that particular aspect of the HURD experiment is not a success and patch system include files. * They could find a way to patch pam only for HURD. I think that would be a bad precedent, but I couldn't stop them. * They could take the issue to TC, either as a question about this specific issue, or asking the TC to set policy on what ports patches maintainers should accept. I think this is a good discussion to have though, and so I am soliciting input both from the HURD community and from the broader Debian community.
signature.asc
Description: PGP signature
