Re: so_rerror

[Roy Marples <roy%marples.name@localhost>]

On 04/11/2018 00:49, Christos Zoulas wrote:
> | Using the same logic you put forward we should set
> | security.pax.mprotect.enabled=0 because I have a list of programs that
> | don't work with it and when trying to poke people to get it to work they
> | said just disable that option.
>
> With 2 major differences:
>
> 1. pax-mprotect protects the system from random programs that misuse
>     mmap; the class of programs that breaks is small and known (jit stuff);
>     the majority of people think that the default should be on. And finally
>     there is a sysctl to choose... Until I commit the code, the new behavior
>     for sockets is mandatory.

I don't have a single NetBSD system where I can turn this option on (for 
example, it's not found on ERLITE) and have all the programs I need to 
run on it actually work.

It's good to know that the only machine I have where the default out of 
the box config actually works or it's intended use is my ERLITE. That 
can't be said of my x86 or amd64 platforms.

> 2. so_rerror affects random programs (we don't know which ones but any
>     one using sockets can be affected; this set is much larger than the
>     set of programs that mmap +x). The majoriry of people think that the
>     default behavior should be to ignore the error.
>
> The straw that broke my back was that I had to change stuff around
> so that my timemachine backups could work again. I.e. the change
> actually broke things (by making the the backup bandwidth effectively 0).

Can you explain how it was broken and what do you to make it work again?

> Let's remember that I was not initially against the change and I
> tried for a long time to fix whatever broke... And I was the one
> that increased buffers for many things. It is just that increasing
> buffers does not fix the problem in pathological cases, and also
> wastes resources.

Which is why we need a better solution than what we have.
dynamically increasing/decreasing buffer size is a good solution for 
this, which should make everyone happy.

> Nevertheless now everyone can have it the way the like... There is
> a sysctl to turn it on globally and a per-socket setsockopt to override.

And we want a secure system where a lot of useful programs don't run and 
sweeps overflow issues under the carpet by default? Not me!

Roy