Hello, Sam Hartman, le lun. 20 janv. 2025 13:21:32 -0700, a ecrit: > 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.
It should not have, indeed. > * 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. Actually, no. Please see https://darnassus.sceen.net/~hurd-web/faq/foo_max/ Also more details in https://eklitzke.org/path-max-is-tricky Quoting a bit: $ printf '#include <limits.h>\nPATH_MAX' | cpp -P $ d=0123456789; for i in `seq 1 1000`; do mkdir $d; cd $d 2>/dev/null; done $ pwd | wc -c Limiting PATH_MAX to 4096 is just a way to not actually try to think about the problem, and hide the corresponding bugs. > * The kind of dynamic memory handling required for avoiding arbitrary > limits introduces significant complexity. For quite a lot of cases it's a matter of using realpath(path, NULL), getcwd(NULL, 0), or asprintf(). > You need to have some limit at some level to avoid resource exhaustion > attacks. Yes, but depending on the application the limit can vary. Using 4096 as limit can be a bad idea if you might have millions of files. If you have only a few of them you could accept much longer. > 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. In the case of HOST_NAME_MAX, we could indeed define it, because its only meaning is the limitation of gethostname(), which is set by the admin and we can limit that there too, it's not coming from whatever else. > 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. Concerning PATH_MAX, for safety of the software, yes. Samuel
