On Mon, Aug 26, 2024 at 12:06:23PM +0200, Florian Weimer wrote: > * Peter Pentchev: > > > On Thu, Aug 22, 2024 at 05:06:53PM +0200, Florian Weimer wrote: > >> * Lennart Poettering: > >> > 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. > > Yes, that's what I meant with “as the base”. But my test program was > broken, and fixing it allowed me to creat the socket. > > *However*, if you do this, getsockname keeps returning > /proc/self/fd/3/meow even if descriptor 3 is closed. /proc/self/fd is > also visible across process boundaries. I wonder if the socket name is > actually /proc/self/fd/3/meow and not the alternate long name. But then > why does it show up in the file system at this point? Anyway, this > looks like it triggers some sort of kernel bug, so I really don't think > this can be recommended as an approach. Argh, I didn't even think about the "across process boundaries" aspect, and it is actually an important one - I think there is precedent for servers that have an out-of-band way to advertise to clients where the endpoints that they listen on are (at the very least there is varlink, but there surely are other ways, too). So, yeah, you are correct that this should not be recommended as a general approach, even with a list of caveats. Thanks! 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
