Re: `Unix-domain socket path "..." is too long (maximum 107 bytes)` can we change that?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Do, 22.08.24 17:06, Florian Weimer (fweimer@xxxxxxxxxx) wrote:

> > 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?

Internally in systemd, we have a function chase() which basically does
something like canonicalize_file_name(), but built around O_PATH, and
ultimately returning an O_PATH fd. It resolves paths in userspace,
taking alternative roots into account, being careful with symlinks and
so on. As a side effect this means we do not have any limits on paths
lengths anywhere.

I mean, things like this I sense are really fundamental if you want to
safely use the POSIX file system API, without risking being tricked
into opening/creating files one shouldn't use by the various tricks
available. But I have no illusions there:  I think it's really tough
to wrap this into a public libc-level API.

> > 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.

Well, the path gets propagated into what /proc/net/unix shows, hence I
don't think going via /proc/self/fd/ is desriable there. I think the
best option is to use a relative bind then, via chdir() as I
mentioned. It will then just show a relative path, which is not
perfect, but at least communicates clearly what's going on, and still
is descriptive.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux