On Thu, Aug 22, 2024 at 05:06:53PM +0200, Florian Weimer wrote: > * 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. I think the reason is O_PATH - bind(2) is not among the syscalls that it is documented to allow. However, see the attached program that creates a subdirectory with a long name in the current working directory, opens it without O_PATH, but with O_DIRECTORY, and then binds a Unix-domain socket to /proc/self/fd/N; it works for me at least on Debian testing and a month-or-two-old Fedora pre-42 Rawhide. ("Works for me" in the sense that "cd this-...; nc -v -U meow" says that it has connected to the Unix-domain socket; of course, the program does not attempt to communicate with connected clients) > 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. That might actually work, yeah. G'luck, Peter -- Peter Pentchev roam@xxxxxxxxxxx roam@xxxxxxxxxx peter@xxxxxxxxxxxxxx PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Attachment:
signature.asc
Description: PGP signature
-- _______________________________________________ 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
