Re: [go-nuts] Orderly exit

[Kevin Chadwick]

On February 24, 2021 11:37:05 PM UTC, robert engels  
wrote:
>A simple slice OOB causes a panic - this is why many robust servers
>will catch & recover so a single OOB due to bug triggered by rare
>input/state doesn’t crash the server for 1000’s of users. It might
>still cause problems due to resource exhaustion, but properly designed
>exception/error handling should prevent/limit that.

I would rather fail safe than cater for a situation that shouldn't happen. 
Recovery is a less sane environment and there are better ways to build in 
redundancy.

Wrt forking. I was talking about dropping privileges, once at daemon startup.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/D74D9146-B712-4EFF-A291-3A4D7ACA051B%40gmail.com.

Re: [go-nuts] Orderly exit

[robert engels]

A simple slice OOB causes a panic - this is why many robust servers will catch 
& recover so a single OOB due to bug triggered by rare input/state doesn’t 
crash the server for 1000’s of users. It might still cause problems due to 
resource exhaustion, but properly designed exception/error handling should 
prevent/limit that.

> On Feb 24, 2021, at 5:29 PM, Kevin Chadwick  wrote:
> 
> On February 24, 2021 11:16:46 PM UTC, robert engels  
> wrote:
>> I’m sorry but that is not correct. If you have a “server process” that
>> handles requests for 1000’s of clients - terminating the process due to
>> an exception/panic easily leads to a DoS attack. The bad actor only
>> needs to send similar requests infrequently to affect thousands of
>> users - especially with round-robin servicing - you can take down
>> 1000’s of servers with 1:1 requests.
>> 
> 
> I figured after that I should have more politely said that. I am not sure 
> what scenario you are thinking of but it doesn't apply to what I am doing.
> 
> Panics should not be triggerable by external influences, in any case.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CDB3583B-6171-4025-B635-CC680FDDDF0D%40gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/E3AE3FB6-A7D6-4539-A07E-8E5A71AA30D0%40ix.netcom.com.

Re: [go-nuts] Orderly exit

[robert engels]

You can read the section ‘Apache Vulnerabilities’ and the difference in forking 
vs multi-threader Apache configuration and how that triggers a DoS. See 
https://www.feistyduck.com/library/apache-security/online/apachesc-CHP-5.html

> On Feb 24, 2021, at 5:16 PM, robert engels  wrote:
> 
> I’m sorry but that is not correct. If you have a “server process” that 
> handles requests for 1000’s of clients - terminating the process due to an 
> exception/panic easily leads to a DoS attack. The bad actor only needs to 
> send similar requests infrequently to affect thousands of users - especially 
> with round-robin servicing - you can take down 1000’s of servers with 1:1 
> requests.
> 
>> On Feb 24, 2021, at 4:04 PM, Kevin Chadwick  wrote:
>> 
>> On February 24, 2021 8:00:36 PM UTC, Robert Engels  
>> wrote:
>>> Depending on other infrastructure that can easily lead to easy DoS
>>> attacks. 
>> 
>> Utter nonsense, more likely the opposite, if any difference at all.
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/82940662-0589-4C68-AE4A-72AB0DBC36D3%40gmail.com.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/7E95DC15-29E9-436C-9667-A9B7B67A312C%40ix.netcom.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/669CDDDB-D7F8-4DE5-85E6-52905CD8AA27%40ix.netcom.com.

Re: [go-nuts] Orderly exit

[Kevin Chadwick]

On February 24, 2021 11:16:46 PM UTC, robert engels  
wrote:
>I’m sorry but that is not correct. If you have a “server process” that
>handles requests for 1000’s of clients - terminating the process due to
>an exception/panic easily leads to a DoS attack. The bad actor only
>needs to send similar requests infrequently to affect thousands of
>users - especially with round-robin servicing - you can take down
>1000’s of servers with 1:1 requests.
>

I figured after that I should have more politely said that. I am not sure what 
scenario you are thinking of but it doesn't apply to what I am doing.

Panics should not be triggerable by external influences, in any case.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CDB3583B-6171-4025-B635-CC680FDDDF0D%40gmail.com.

Re: [go-nuts] Orderly exit

[robert engels]

I’m sorry but that is not correct. If you have a “server process” that handles 
requests for 1000’s of clients - terminating the process due to an 
exception/panic easily leads to a DoS attack. The bad actor only needs to send 
similar requests infrequently to affect thousands of users - especially with 
round-robin servicing - you can take down 1000’s of servers with 1:1 requests.

> On Feb 24, 2021, at 4:04 PM, Kevin Chadwick  wrote:
> 
> On February 24, 2021 8:00:36 PM UTC, Robert Engels  
> wrote:
>> Depending on other infrastructure that can easily lead to easy DoS
>> attacks. 
> 
> Utter nonsense, more likely the opposite, if any difference at all.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/82940662-0589-4C68-AE4A-72AB0DBC36D3%40gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7E95DC15-29E9-436C-9667-A9B7B67A312C%40ix.netcom.com.

Re: [go-nuts] Orderly exit

[Kevin Chadwick]

On February 24, 2021 8:00:36 PM UTC, Robert Engels  
wrote:
>Depending on other infrastructure that can easily lead to easy DoS
>attacks. 

Utter nonsense, more likely the opposite, if any difference at all.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/82940662-0589-4C68-AE4A-72AB0DBC36D3%40gmail.com.

Re: [go-nuts] Orderly exit

[Robert Engels]

Depending on other infrastructure that can easily lead to easy DoS attacks. 

> On Feb 24, 2021, at 12:15 PM, Kevin Chadwick  wrote:
> 
> On 2/24/21 9:53 AM, roger peppe wrote:
>> On Tue, 23 Feb 2021 at 12:10, Kevin Chadwick > > wrote:
>> 
>>I only instigate panic manually for one thing. Perhaps that will change, 
>> but
>>I doubt it.
>> 
>>If I want to send out or write a log to disk then I will call panic rather
>>than os.exit, upon a log.fatal scenario. Think buffered go routine 
>> logging.
>>Saving the coder from having to think about it, once initialised.
>> 
>>Which produces some ugly output and likely extra processing.
>> 
>>Is it possible to call panic in a way that does not kill the process like
>>os.Exit, but without log pollution?
>> 
>>I am solely thinking of manually instigated panics, so a noop panic called
>>something like terminate?
>> 
>>Or is this bad practice, even when a program is in good operational order
>>when instigated, as the OS is better at cleanup?
>> 
>> 
>> Personally, I'd advise against using panic or log.Fatal in this kind of 
>> context
>> - I'd just bite the bullet and return errors instead.
>> This makes it easy to move code between contexts if you need to without 
>> worrying
>> about non-local control flow.
>> 
> 
> Yes, I avoid log.Fatal, wherever possible.
> 
> However, if I am for example running a drop privileges function and it fails
> then I want an immediate exit. To avoid any potential of fragility.
> 
> Actually it seems that the panic never gets logged anyway and as the master
> process is unlikely to fatal then a panic is unlikely to ever be seen. Perhaps
> not ideal, but it works.
> 
>> For unexpected panics, you can still use recover to flush your log buffers,
>> assuming the panic happens in code that's been called by your code.
> 
> I think I would rather os.Exit ASAP, in the case of an unexpected panic.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/84a0db02-c4ec-15cf-cdd9-8543c1f9aa61%40gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/D4AF8F93-2412-4C11-B292-087CA0960C90%40ix.netcom.com.

Re: [go-nuts] Orderly exit

[Kevin Chadwick]

On 2/24/21 9:53 AM, roger peppe wrote:
> On Tue, 23 Feb 2021 at 12:10, Kevin Chadwick  > wrote:
> 
> I only instigate panic manually for one thing. Perhaps that will change, 
> but
> I doubt it.
> 
> If I want to send out or write a log to disk then I will call panic rather
> than os.exit, upon a log.fatal scenario. Think buffered go routine 
> logging.
> Saving the coder from having to think about it, once initialised.
> 
> Which produces some ugly output and likely extra processing.
> 
> Is it possible to call panic in a way that does not kill the process like
> os.Exit, but without log pollution?
> 
> I am solely thinking of manually instigated panics, so a noop panic called
> something like terminate?
> 
> Or is this bad practice, even when a program is in good operational order
> when instigated, as the OS is better at cleanup?
> 
> 
> Personally, I'd advise against using panic or log.Fatal in this kind of 
> context
> - I'd just bite the bullet and return errors instead.
> This makes it easy to move code between contexts if you need to without 
> worrying
> about non-local control flow.
> 

Yes, I avoid log.Fatal, wherever possible.

However, if I am for example running a drop privileges function and it fails
then I want an immediate exit. To avoid any potential of fragility.

Actually it seems that the panic never gets logged anyway and as the master
process is unlikely to fatal then a panic is unlikely to ever be seen. Perhaps
not ideal, but it works.

> For unexpected panics, you can still use recover to flush your log buffers,
> assuming the panic happens in code that's been called by your code.

I think I would rather os.Exit ASAP, in the case of an unexpected panic.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/84a0db02-c4ec-15cf-cdd9-8543c1f9aa61%40gmail.com.

Re: [go-nuts] Orderly exit

[roger peppe]

On Tue, 23 Feb 2021 at 12:10, Kevin Chadwick  wrote:

> I only instigate panic manually for one thing. Perhaps that will change,
> but I doubt it.
>
> If I want to send out or write a log to disk then I will call panic rather
> than os.exit, upon a log.fatal scenario. Think buffered go routine logging.
> Saving the coder from having to think about it, once initialised.
>
> Which produces some ugly output and likely extra processing.
>
> Is it possible to call panic in a way that does not kill the process like
> os.Exit, but without log pollution?
>
> I am solely thinking of manually instigated panics, so a noop panic called
> something like terminate?
>
> Or is this bad practice, even when a program is in good operational order
> when instigated, as the OS is better at cleanup?
>

Personally, I'd advise against using panic or log.Fatal in this kind of
context - I'd just bite the bullet and return errors instead.
This makes it easy to move code between contexts if you need to without
worrying about non-local control flow.

For unexpected panics, you can still use recover to flush your log buffers,
assuming the panic happens in code that's been called by your code.

  cheers,
   rog.

>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/3A8FA632-4991-4245-ABB3-8F4CE1164703%40gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJhgacg0q31bn5K9SeyUmW%2BKjEg-d31xov095ixAn9Zs9VShEg%40mail.gmail.com.

Re: [go-nuts] Orderly exit

[Kevin Chadwick]

> So you should probably disregard the sentinel-panic idea,  
> runtime.Goexit seems strictly superior) 

Thank you. I shall look into those. 

WRT Goexit. I was hoping a defer in main would run also. Thinking about it. I 
shall have to ponder about the relationship of panic and process groups too and 
whether a dedicated service like syslog is better. I may as well use syslog in 
that case but I had cross platform logging code that I figured, may be more 
flexible.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7E3A6D6D-1BAE-4F8E-8259-61B59D5C8731%40gmail.com.

Re: [go-nuts] Orderly exit

['Axel Wagner' via golang-nuts]

(PS: I've only learned about runtime.Goexit after I came up with the
sentinel-panic pattern. I've been thinking for a while, that it is probably
a better choice, for various reasons. And after testing it out,
 I do think it's strictly superior.
So you should probably disregard the sentinel-panic idea, runtime.Goexit
seems strictly superior)

On Tue, Feb 23, 2021 at 1:49 PM Axel Wagner 
wrote:

> On Tue, Feb 23, 2021 at 1:10 PM Kevin Chadwick 
> wrote:
>
>> Is it possible to call panic in a way that does not kill the process like
>> os.Exit, but without log pollution?
>
>
>
> I am solely thinking of manually instigated panics, so a noop panic called
>> something like terminate?
>>
>
> You can `recover`. It's possible to use a private sentinel value to detect
> if a panic was caused by a known code-path or not and re-panic if not. For
> example, I sometimes use this pattern
>  in parsers. It does have some
> downsides though - for example, if you do have to re-panic, you lose some
> context about where the bug happened.
>
> There is also runtime.Goexit ,
> which aborts a running goroutine, calling deferred handlers, but doesn't
> exit the program and doesn't log anything (and can't be recovered). It's
> used by `t.Fatal` and friends.
> However, one thing to keep in mind is that this *might* cause problems if
> code isn't prepared for it. For example, it's natural to assume that a
> function either panics or runs to completion. And it might assume that it's
> fine to leave corrupted state because a panic should crash the program - or
> it might use `recover` to check if a panic occurred and conclude that none
> did when it gets `nil`. Technically, such code is wrong - it makes wrong
> assumptions about Go, like forgetting that panics exist, that Goexit exists
> or that panic(nil) is possible.
>
> But buggy or not - they are natural assumptions to make and such code does
> exist and you might trigger subtle bugs by doing anything of the above. So
> in general, I would prefer orderly control flow, unless you can make
> reasonable assumptions about the code you are skipping over. For example,
> it's probably fine to trigger a bug like that in test code, because at
> worst, it will make the test fail (correctly detecting a bug) or the
> process will exit when the test is finished, cleaning up things. For
> example, I'm fine using the sentinel-panic pattern in parsers, because I
> control the code it's calling into and can make sure it only modifies state
> in a way compatible with the pattern.
>
> For something like a logging framework, I would strongly prefer orderly
> control flow, crashing panics or no error checking. The code it's used in
> is largely unknown. And either logging is considered critical, in which
> case it needs to be checked or should crash if it fails, or it's not
> considered critical, in which case there's nothing to be done about an
> error and you might as well ignore it.
>
>
>> Or is this bad practice, even when a program is in good operational order
>> when instigated, as the OS is better at cleanup?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/3A8FA632-4991-4245-ABB3-8F4CE1164703%40gmail.com
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHmAFGt6Ej-rguraZAx_at6Lh8KB-1dBMXZjdOyF11UZQ%40mail.gmail.com.

Re: [go-nuts] Orderly exit

['Axel Wagner' via golang-nuts]

On Tue, Feb 23, 2021 at 1:10 PM Kevin Chadwick  wrote:

> Is it possible to call panic in a way that does not kill the process like
> os.Exit, but without log pollution?



I am solely thinking of manually instigated panics, so a noop panic called
> something like terminate?
>

You can `recover`. It's possible to use a private sentinel value to detect
if a panic was caused by a known code-path or not and re-panic if not. For
example, I sometimes use this pattern
 in parsers. It does have some
downsides though - for example, if you do have to re-panic, you lose some
context about where the bug happened.

There is also runtime.Goexit ,
which aborts a running goroutine, calling deferred handlers, but doesn't
exit the program and doesn't log anything (and can't be recovered). It's
used by `t.Fatal` and friends.
However, one thing to keep in mind is that this *might* cause problems if
code isn't prepared for it. For example, it's natural to assume that a
function either panics or runs to completion. And it might assume that it's
fine to leave corrupted state because a panic should crash the program - or
it might use `recover` to check if a panic occurred and conclude that none
did when it gets `nil`. Technically, such code is wrong - it makes wrong
assumptions about Go, like forgetting that panics exist, that Goexit exists
or that panic(nil) is possible.

But buggy or not - they are natural assumptions to make and such code does
exist and you might trigger subtle bugs by doing anything of the above. So
in general, I would prefer orderly control flow, unless you can make
reasonable assumptions about the code you are skipping over. For example,
it's probably fine to trigger a bug like that in test code, because at
worst, it will make the test fail (correctly detecting a bug) or the
process will exit when the test is finished, cleaning up things. For
example, I'm fine using the sentinel-panic pattern in parsers, because I
control the code it's calling into and can make sure it only modifies state
in a way compatible with the pattern.

For something like a logging framework, I would strongly prefer orderly
control flow, crashing panics or no error checking. The code it's used in
is largely unknown. And either logging is considered critical, in which
case it needs to be checked or should crash if it fails, or it's not
considered critical, in which case there's nothing to be done about an
error and you might as well ignore it.


> Or is this bad practice, even when a program is in good operational order
> when instigated, as the OS is better at cleanup?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/3A8FA632-4991-4245-ABB3-8F4CE1164703%40gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEVM%2B6f_TRz9aKcFCVhd_R5UxRFy1eWJBW-oZpEH12v%2BA%40mail.gmail.com.