4 ms·

The Linux kernel doesn't have an actual path limit. Nor does Solaris. PATH_MAX is 4096 in glibc and musl libc because setting to it to something like INT_MAX or

by wahern 5y ago

The Linux kernel doesn't have an actual path limit. Nor does Solaris. PATH_MAX is 4096 in glibc and musl libc because setting to it to something like INT_MAX or ULONG_MAX would break a lot of existing code that uses PATH_MAX to size buffers. (Though Solaris does define it as INT_MAX, IIRC.) OTOH, because of the lack of a hard limit there's also code that relies (if accidentally) on paths longer than PATH_MAX.

jwilk 5y ago
Linux does have a limit, at least for some system calls: $ strace -e trace=file perl -e 'open(FH, "<", "/" x 4096)' … openat(AT_FDCWD, "//////////…"..., O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENAMETOOLONG (File name too long) +++ exited with 0 +++
- wahern 5y ago
  I stand corrected. It seems that Linux copies the entire path into a kernel-allocated buffer (see getname and getname_flags in fs/namei.c as called by various syscalls in fs/open.c), rejecting paths longer than PATH_MAX. EDIT: And on Solaris PATH_MAX is 1024 and (AFAICT) Solaris also copies paths into kernel space. It seems I was confusing things with NL_TEXTMAX, which is INT_MAX on glibc (but not Solaris).
- yencabulator 5y ago
  There's a limit to what path string you can make the kernel interpret. That does not limit total path length. Keep looping on mkdirat/openat and you can make very very deep trees. As opposed to your syscall that is relative to an arbitrary directory, /proc/self/mountinfo has to contain the whole absolute path to be useful.
yrro 5y ago
https://eklitzke.org/path-max-is-tricky https://eklitzke.org/path-max-is-tricky The Linux kernel defines upper limits for NAME_MAX (255) and PATH_MAX (4096). The glibc doesn't enforce this limit because it was originally written to run on GNU HURD which I guess doesn't have these limits. But systemd only runs on glibc on Linux. So I don't see why it doesn't at least sanity check the length of absolute paths with PATH_MAX...

by wahern 5y ago

jwilk 5y ago

Linux does have a limit, at least for some system calls: $ strace -e trace=file perl -e 'open(FH, "<", "/" x 4096)' … openat(AT_FDCWD, "//////////…"..., O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENAMETOOLONG (File name too long) +++ exited with 0 +++

wahern 5y ago
I stand corrected. It seems that Linux copies the entire path into a kernel-allocated buffer (see getname and getname_flags in fs/namei.c as called by various syscalls in fs/open.c), rejecting paths longer than PATH_MAX. EDIT: And on Solaris PATH_MAX is 1024 and (AFAICT) Solaris also copies paths into kernel space. It seems I was confusing things with NL_TEXTMAX, which is INT_MAX on glibc (but not Solaris).
yencabulator 5y ago
There's a limit to what path string you can make the kernel interpret. That does not limit total path length. Keep looping on mkdirat/openat and you can make very very deep trees. As opposed to your syscall that is relative to an arbitrary directory, /proc/self/mountinfo has to contain the whole absolute path to be useful.

yrro 5y ago

https://eklitzke.org/path-max-is-tricky https://eklitzke.org/path-max-is-tricky The Linux kernel defines upper limits for NAME_MAX (255) and PATH_MAX (4096). The glibc doesn't enforce this limit because it was originally written to run on GNU HURD which I guess doesn't have these limits. But systemd only runs on glibc on Linux. So I don't see why it doesn't at least sanity check the length of absolute paths with PATH_MAX...