On Wed, Jul 2, 2025 at 7:19 AM Jukka Laitinen wrote:
> Hi,
>
> I didn't follow the full discussion, but we had similar problems with
> sockets, file descriptors and dup. Just to draw your attention, this was
> the PR / patches where the issue was fixed:
>
> https://github.com/apache/nuttx/pull/16
Hi,
I didn't follow the full discussion, but we had similar problems with
sockets, file descriptors and dup. Just to draw your attention, this was
the PR / patches where the issue was fixed:
https://github.com/apache/nuttx/pull/16499 (originally
https://github.com/apache/nuttx/pull/16361)
I have wasted WAY too many days trying to understand what's going on
here: you start on the premise that it "must of worked" but I am really
not so sure with this!
I think the idea of the timeout is simply to cover the case that the CGI
"app" goes AWOL and needs to be killed, if so configured
Hi Tim,
Understood, now it is clear why it stopped working.
Maybe Wanggang didn't test it with CGI support.
BR,
Alan
On Tue, Jul 1, 2025 at 3:23 PM Tim Hardisty wrote:
> The "FD" is not "executed" as such. It is used to send data to the open
> socket from a CGI app that is run via an exec()
Out of curiosity I just took a look into the thhtp cgi code and noticed
something I don't understand myself.
There is the cgi_child(), which looks like it is to be called after a fork
for the child case.
It prepares the filedescriptors and calls exec.
The result of the exec is stored in a variable
The "FD" is not "executed" as such. It is used to send data to the open
socket from a CGI app that is run via an exec() call. The O_CLOEXEC
however causes the FD to be closed on the exec(), and the dup2() that
happens in that exec'd CGI handling gets reissued with the same number,
meaning the
Hi Tim,
You are right, it doesn't execute, but some subprocess (like a CGI) could
try to execute.
This comment there shed some light about it:
"I wouldn't describe O_CLOEXEC as there principally for privilege
escalation / security reasons -- it's also very,
very common to have non-security bugs
But that's the point - thttp *does* call exec() so the open socket file
descriptor gets closed when it is still needed by the exec'd application.
If there's another way of doing this I'm listening!
On 01/07/2025 16:13, Alan C. Assis wrote:
Hi Tim,
Nice finding!
Now we need to understand why
Hi Tim,
Nice finding!
Now we need to understand why this worked in the past and now it doesn't.
Also, what are the implications of removing SOCK_CLOEXEC? A few pointers
here:
https://stackoverflow.com/questions/22304631/what-is-the-purpose-to-set-sock-cloexec-flag-with-accept4-same-as-o-cloexec
The error was, indeed, the socket being opened with the SOCK_CLOEXEC
flasg set.
PR to follow.
On 28/06/2025 16:16, Tim Hardisty wrote:
Actually - it might be a change last year. The socket is now opened
like this and I assume CLOEXEC will mess up the operation of the
executed CGI app (will in
Actually - it might be a change last year. The socket is now opened like
this and I assume CLOEXEC will mess up the operation of the executed CGI
app (will investigate on Monday; not sure what socket mode it needs to be):
hc->conn_fd = accept4(listen_fd, (struct sockaddr *)&sa, &sz, SOCK_CLOEXE
Hi Tim,
Yes, I think send() is the preferred form to work with sockets because you
can have fine control, i.e. passing flags at forth argument (MSG_DONTWAIT,
etc).
If you suspect that the bug was caused by some recent modification, try to
find a supported board that was used to test thttpd in the
Is it as "simple" as thttpd should do:
nwritten= send(sock_fd, buffer, totalbytesread, 0);
rather than the generic:
nwritten= write(sock_fd, buffer, nbytes);
On 27/06/2025 18:40, Tim Hardisty wrote:
Trying to get thttpd's CGI handling working and have found that the
dup(2) calls of stdin and
Trying to get thttpd's CGI handling working and have found that the
dup(2) calls of stdin and stdout return a file descriptor that's already
been allocated to the NET socket (via thttpd I think).
That isn't right is it?
I am not sure if it's a side effect of something that thttpd does (that
m
14 matches
Mail list logo
