Re: Busybox httpd sends output of stderr to the Website

[Laurent Bercot]

https://www.freebsd.org/cgi/man.cgi?query=inetd

"Theserver program isinvokedwith the service socket
as its standardinput, output  and error descriptors"


Show me an implementation of inetd which does not do this.


 Oh, I'm not pretending wikipedia is wrong. I was just amused by your
choice to quote it (as opposed to, for instance, the FreeBSD man page
for inetd that you now quoted).

 And my main point here is that it's a suboptimal design choice, and for
that reason and others, tcpserver should be preferred.

--
 Laurent

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Busybox httpd sends output of stderr to the Website

[Denys Vlasenko]

On Sat, Mar 25, 2017 at 9:04 AM, Laurent Bercot
 wrote:
>> Unless they do want _remote user_ to see the message.
>>
>> For example, if you start a shell over a tcp connection
>> ("poor man's telnet"), you do want to see shell error messages
>> when you work in that shell, right?
>>
>> IOW: inetd can't know which behavior is desirable, since both make sense.
>>
>> So the best thing is to follow the existing established practice
>> (if it exists). I googled for it and there is a somewhat weak indication
>> that inetd's of various Unixes did send stderr to the socket.
>> Even wikipedia says:
>> "...
>> inetd hooks the sockets directly to stdin, stdout and stderr
>> of the spawned process"
>
>
>  Ah, wikipedia, that famous normative specification site. ;)

https://www.freebsd.org/cgi/man.cgi?query=inetd

"Theserver program isinvokedwith the service socket
as its standardinput, output  and error descriptors"


Show me an implementation of inetd which does not do this.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Busybox httpd sends output of stderr to the Website

[Laurent Bercot]

Unless they do want _remote user_ to see the message.

For example, if you start a shell over a tcp connection
("poor man's telnet"), you do want to see shell error messages
when you work in that shell, right?

IOW: inetd can't know which behavior is desirable, since both make 
sense.


So the best thing is to follow the existing established practice
(if it exists). I googled for it and there is a somewhat weak 
indication

that inetd's of various Unixes did send stderr to the socket.
Even wikipedia says:
"...
inetd hooks the sockets directly to stdin, stdout and stderr
of the spawned process"


 Ah, wikipedia, that famous normative specification site. ;)

 Note that if stderr is not automatically redirected to the client,
it is easy for a service to do so if it wishes: run
"sh -c 'exec foobard 2>&1'" instead of "foobard".
 And if the service does not want stderr redirected, then it has nothing
to do - the infrastructure running the service is in charge of sending
stderr to an appropriate logging place. This is the behaviour of 
tcpserver

with a supervision suite such as s6 or runit, where the supervision tree
also manages a logging chain and services can do what they want with
their stderr - redirect it to the client, get their own logger, or just
let the supervision tree handle it (i.e. send it to the default system
logger).

 Whereas if stderr is automatically redirected to the client by the
superserver (which is the case with bb's inetd), then everything's fine
as long as all services want that behaviour, but if a service does *not*
want its stderr redirected, what should it do? There is no "let the
infrastructure handle it" option. The service has to choose a place for
its stderr to go, and the choices are bleak: /dev/null, a log file
(which can grow uncontrollably), or a fifo to a previously defined
logging program that cannot take advantage of the superserver model and
that the inetd service is silently relying on. That's more brittle, and
more work for the administrator.

 I really recommend not using inetd and spawning a tcpserver process
instead for every inetd-mode service you have. It is much more 
comfortable

to admin in the long run.

--
 Laurent

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Busybox httpd sends output of stderr to the Website

[Denys Vlasenko]

On Thu, Mar 23, 2017 at 11:45 AM, Steve Bennett  wrote:
>
>> On 23 Mar 2017, at 5:51 PM, Dirk Lohse  wrote:
>>
>> A workaround for me is to not use inetd mode. But the reason for this 
>> behavior should be found and fixed - I think.
>>
>> Dirk
>>
>
> See networking/inetd.c:
>
> /* manpages of inetd I managed to find either say
>  * that stderr is also redirected to the network,
>  * or do not talk about redirection at all (!) */
> if (!sep->se_wait) /* only for usual "tcp nowait" */
> xdup2(STDIN_FILENO, STDERR_FILENO);
>
> inetd is tying stdout and stderr together.
>
> Personally I think this is wrong since it generally means that
> inetd services must be careful never to write to stderr.

Unless they do want _remote user_ to see the message.

For example, if you start a shell over a tcp connection
("poor man's telnet"), you do want to see shell error messages
when you work in that shell, right?

IOW: inetd can't know which behavior is desirable, since both make sense.

So the best thing is to follow the existing established practice
(if it exists). I googled for it and there is a somewhat weak indication
that inetd's of various Unixes did send stderr to the socket.
Even wikipedia says:
"...
inetd hooks the sockets directly to stdin, stdout and stderr
of the spawned process"
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Busybox httpd sends output of stderr to the Website

[Laurent Bercot]

inetd is tying stdout and stderr together.

Personally I think this is wrong since it generally means that
inetd services must be careful never to write to stderr.


 Use tcpserver instead of inetd. It allows you to use the "inetd mode"
in applets, and does not exhibit the problems that inetd does.

--
 Laurent

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Busybox httpd sends output of stderr to the Website

[Steve Bennett]

> On 23 Mar 2017, at 5:51 PM, Dirk Lohse  wrote:
> 
> A workaround for me is to not use inetd mode. But the reason for this 
> behavior should be found and fixed - I think.
> 
> Dirk
> 

See networking/inetd.c:

/* manpages of inetd I managed to find either say
 * that stderr is also redirected to the network,
 * or do not talk about redirection at all (!) */
if (!sep->se_wait) /* only for usual "tcp nowait" */
xdup2(STDIN_FILENO, STDERR_FILENO);

inetd is tying stdout and stderr together.

Personally I think this is wrong since it generally means that
inetd services must be careful never to write to stderr.

Cheers,
Steve


--
Embedded Systems Specialists - http://workware.net.au/
WorkWare Systems Pty Ltd
W: www.workware.net.au  P: +61 434 921 300
E: ste...@workware.net.au







___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Busybox httpd sends output of stderr to the Website

[Guillermo Rodriguez Garcia]

Not sure why that happens (I mean stderr behaviour being different
when httpd is started via inetd) but at least now you have solved your
issue.

Guillermo

2017-03-22 15:03 GMT+01:00 Dirk Lohse <d.lo...@meier-nt.de>:
> Hi,
>
> there is a difference between starting httpd in inetd and standalone/daemon 
> mode!
>
> I tried my test script in inetd mode
>   www stream tcp nowait root /bin/busybox httpd -i -u httpd -h /srv/www
> and I see the text I would not see. Btw: 
> http://lists.busybox.net/pipermail/busybox/2007-May/061465.html
>
> Starting it from cmdline with
>   httpd -h /srv/www
> it works like expected. A nice feature I found is starting with "-f" Don't 
> daemonize and I can see the output from stderr on cmdline. This makes 
> debugging quite easier :)
>
> Dirk
>
> -Ursprüngliche Nachricht-
> Von: Guillermo Rodriguez Garcia [mailto:guille.rodrig...@gmail.com]
> Gesendet: Dienstag, 21. März 2017 18:13
> An: Dirk Lohse
> Cc: busybox@busybox.net
> Betreff: Re: Busybox httpd sends output of stderr to the Website
>
> Looking at the source code of httpd.c from busybox 1.20.2 I see this 
> (send_cgi_and_exit, line 1408)
>
> /* User seeing stderr output can be a security problem.
> * If CGI really wants that, it can always do dup itself. */
> /* dup2(1, 2); */
>
> So it looks like it should be doing the right thing already (i.e. not sending 
> the child's stderr to its output)
>
> Where is your busybox 1.20.2 coming from? Perhaps there have been 3rd party 
> patches applied to it?
>
> Guillermo
>
> 2017-03-21 17:37 GMT+01:00 Dirk Lohse <d.lo...@meier-nt.de>:
>> Hi,
>>
>> when i run some cgi's with BusyBox internal httpd and there is some code 
>> that writes to stdout I get the result on the HTTP site - which is desired - 
>> because I produce HTTP-code within this cgi scripts. The output of stderr 
>> instead should not destroy my HTML-code and could be redirected to /dev/null.
>>
>> In BusyBox v1.19.4 all was fine. But on BusyBox version v1.20.2 httpd 
>> redirects output from stdout + stderr to the HTML-code.
>>
>> I've written a small test script to check this behavior on both versions:
>>
>> test.cgi:
>> #!/bin/sh
>>
>> echo "Content-Type: text/plain"
>> echo "Expires: 0"
>> echo
>>
>> echo "Hello World!"
>> echo "You should not see this text in your Browser" >&2
>>
>> when I call this script on the older version, I only see "Hello World!", on 
>> the new version instead I see also the last line.
>>
>> I've many code and libraries where everywhere an error message or warning 
>> could happen on stdout. So changing all the code is nearly impossible, and 
>> some warnings like "can't open file..." are necessary for debugging.
>>
>> My question: How can I tell the httpd to NOT redirect stdout to the website?
>>
>> Thanks,
>> Dirk
>>
>>
>> ___
>> busybox mailing list
>> busybox@busybox.net
>> http://lists.busybox.net/mailman/listinfo/busybox
>
>
>
> --
> Guillermo Rodriguez Garcia
> guille.rodrig...@gmail.com



-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Busybox httpd sends output of stderr to the Website

[Bob Dunlop]

> My question: How can I tell the httpd to NOT redirect stdout to the website?

Or you could tell your CGI programs not to generate data on stderr.

In your example for instance.

  #!/bin/sh

  # Redirect stderr, not required in production
  exec 2>/dev/null

  echo "Content-Type: text/plain"
  echo "Expires: 0"
  echo

  echo "Hello World!"
  echo "You should not see this text in your Browser" >&2

HTH
-- 
Bob Dunlop
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Busybox httpd sends output of stderr to the Website

[Guillermo Rodriguez Garcia]

Looking at the source code of httpd.c from busybox 1.20.2 I see this
(send_cgi_and_exit, line 1408)

/* User seeing stderr output can be a security problem.
* If CGI really wants that, it can always do dup itself. */
/* dup2(1, 2); */

So it looks like it should be doing the right thing already (i.e. not
sending the child's stderr to its output)

Where is your busybox 1.20.2 coming from? Perhaps there have been 3rd
party patches applied to it?

Guillermo

2017-03-21 17:37 GMT+01:00 Dirk Lohse :
> Hi,
>
> when i run some cgi's with BusyBox internal httpd and there is some code that 
> writes to stdout I get the result on the HTTP site - which is desired - 
> because I produce HTTP-code within this cgi scripts. The output of stderr 
> instead should not destroy my HTML-code and could be redirected to /dev/null.
>
> In BusyBox v1.19.4 all was fine. But on BusyBox version v1.20.2 httpd 
> redirects output from stdout + stderr to the HTML-code.
>
> I've written a small test script to check this behavior on both versions:
>
> test.cgi:
> #!/bin/sh
>
> echo "Content-Type: text/plain"
> echo "Expires: 0"
> echo
>
> echo "Hello World!"
> echo "You should not see this text in your Browser" >&2
>
> when I call this script on the older version, I only see "Hello World!", on 
> the new version instead I see also the last line.
>
> I've many code and libraries where everywhere an error message or warning 
> could happen on stdout. So changing all the code is nearly impossible, and 
> some warnings like "can't open file..." are necessary for debugging.
>
> My question: How can I tell the httpd to NOT redirect stdout to the website?
>
> Thanks,
> Dirk
>
>
> ___
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox



-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox