* Lennart Poettering: > On Mi, 07.08.24 13:09, Vít Ondruch (vondruch@xxxxxxxxxx) wrote: > >> With new RPM, I hit the limit in two packages: >> >> https://koschei.fedoraproject.org/package/rubygem-abrt >> >> https://koschei.fedoraproject.org/package/rubygem-pg >> >> >> I have read: >> >> https://unix.stackexchange.com/questions/367008/why-is-socket-path-length-limited-to-a-hundred-chars >> >> https://stackoverflow.com/questions/34829600/why-is-the-maximal-path-length-allowed-for-unix-sockets-on-linux-108 >> >> >> But I still wonder why we should live with such limitation in 21st century. > > You don't really have to live with such a limitation. In systemd we > have code that works around this limitation via O_PATH. i.e. when > connect()ing you first open the socket inode with O_PATH, and then you > fire the connect() specifying /proc/self/fd/<fd> as path. That always > fits into the 108ch limit. Do you think this is useful more generally? What about opening files with names longer than PATH_MAX? > bind()ing to an overly long unix socket path is also doable, but > harder (since you cannot O_PATH on an inode that doesn't exist > yet). The way I'd do it is via chdir() to the dir of the target path > and binding to a relative path then. But chdir() is of course icky, > since it's a global property of a process, hence will affect all > threads. Hence, maybe do this in a short-lived forked off process. I would have expected that it's possible to use a directory descriptor under /proc/self/fd as the base, but that doesn't seem to work for some reason. You could also use a long-lived service thread that has called unshare(CLONE_FS), so that it has its own current directory. This is a bit iffy because glibc won't know about it, but it's already used by some popular file servers, so it should be okay. I've posted a patch that implements a proper NPTL facility for this, but it met with a surprising amount of resistance. I suppose I could dust it off and repost it. Thanks, Florian -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
