Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: feature request: support specifying Unix socket with systemd directive OpenFile=
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Emanuele Torre via curl-users <curl-users_at_lists.haxx.se>
Date: Tue, 20 Jun 2023 22:24:33 +0200
On Tue, Jun 20, 2023 at 03:59:00PM -0400, Timothe Litt via curl-users wrote:
> /dev/fd/123
>
On linux (systemd only runs on linux), /dev/fd/123 is only a symbolic
link to the path of the opened file (a magic symbolic link that resolves
correctly even if the original path was replaced by a new file).
fd = open("/dev/fd/123",O_RDONLY) is not equivalent to fd = dup(123)
as long as 123 has read permissions, and a failure otherwise, that is
the FreeBSD behaviour.
On linux, that will just make the process open a second independent file
descriptor to the same file used by fd 123.
So open("/dev/fd/123",O_RDONLY) will open a new file descriptor to
that file, and the process would need permissions to open it. If the
user doesn't have permissions to do that as its the case here, that is
not an option. If the file is a regular file, the new fd will have its
offset at the start of the file. If you used O_TRUNC when opening the
file, the file will be truncated everywhere, etc.
On top of that, here for --unix-socket, curl is using that path to
connect to a UNIX socket, not just to open it, so I am not sure that
would work even on FreeBSD.
Unless you are suggesting that curl should parse the file paths it uses
to check if they are "/dev/fd/" followed by a number, and, if they are,
use that number as file descriptor directly without trying to open or
connect that path, I am afraid your suggestion can't work.
o/
emanuele6
Date: Tue, 20 Jun 2023 22:24:33 +0200
On Tue, Jun 20, 2023 at 03:59:00PM -0400, Timothe Litt via curl-users wrote:
> /dev/fd/123
>
On linux (systemd only runs on linux), /dev/fd/123 is only a symbolic
link to the path of the opened file (a magic symbolic link that resolves
correctly even if the original path was replaced by a new file).
fd = open("/dev/fd/123",O_RDONLY) is not equivalent to fd = dup(123)
as long as 123 has read permissions, and a failure otherwise, that is
the FreeBSD behaviour.
On linux, that will just make the process open a second independent file
descriptor to the same file used by fd 123.
So open("/dev/fd/123",O_RDONLY) will open a new file descriptor to
that file, and the process would need permissions to open it. If the
user doesn't have permissions to do that as its the case here, that is
not an option. If the file is a regular file, the new fd will have its
offset at the start of the file. If you used O_TRUNC when opening the
file, the file will be truncated everywhere, etc.
On top of that, here for --unix-socket, curl is using that path to
connect to a UNIX socket, not just to open it, so I am not sure that
would work even on FreeBSD.
Unless you are suggesting that curl should parse the file paths it uses
to check if they are "/dev/fd/" followed by a number, and, if they are,
use that number as file descriptor directly without trying to open or
connect that path, I am afraid your suggestion can't work.
o/
emanuele6
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-06-20