>>>>> "Samuel" == Samuel Thibault <sthiba...@debian.org> writes:
Samuel> Hello, Sam Hartman, le lun. 20 janv. 2025 13:21:32 -0700, a
Samuel> 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.
Samuel> 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.
Samuel> Actually, no.
Oh, hmm.
Thanks for educating me.
Samuel> Please see
Samuel> https://darnassus.sceen.net/~hurd-web/faq/foo_max/
You quoted the example from the FAQ, although I found it hard to parse.
My restatement is that it's possible to create paths where the full path
name is longer than PATH_MAX.
I guess a better way to look at this would be that paths beyond PATH_MAX
may break. Good coders are responsible for making sure that they break
in a security-preserving manner, but nothing actually prevents them from
existing.
I now agree the situation is more complicated than I thought.
I am still not sure that HURD's approach is an improvement over defining
PATH_MAX.
I suspect that it's valuable to have a consistent PATH_MAX across a
distribution.
I suspect that in practice what people do (and what HURD porters
generally do when supplying patches) is pick a number and define
PATH_MAX.
So, I'm not at all convinced that the HURD approach adds significant
value in a distribution like Debian.
(It appears pam upstream has accepted someone's patch to conditionalize
definitions of PATH_MAX. I'm a bit horrified about how many #ifndef
PATH_MAX there are in pam_mkhomedir_helper, but at least for pam, the
question of PATH_MAX appears theoretical.)
signature.asc
Description: PGP signature
