Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Igor Podlesny
On Sun, 28 Apr 2019 at 02:43, Thomas Frohwein  wrote:
>
> On Sun, Apr 28, 2019 at 02:07:44AM +0700, Igor Podlesny wrote:
> [...]
> > Looks like decision made aren't subjects of discussing(?) Well, why
> > the hell you have those mail lists then(?) :)
>
> Igor:
> The actual purpose of misc@ is for us to learn that you are among the people 
> to
> ignore.

You don't understand what "to ignore" mean then. Or fail to do what
you say. Or learn too slow. ;-)

-- 
End of message. Next message?



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Consus
On 12:43 Sat 27 Apr, Thomas Frohwein wrote:
> Move along, nothing to see here.

I want to see more butthurting Theo!



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread chohag
Otto Moerbeek writes:
>
> The mechanism is in the docs as well, not only in the code. You

You are of course correct, and OpenBSD has some of the best documentation
I've ever seen, but I've spent so long in linux land that whenever I'm
met with the question of how *exactly* something works, I just go straight
to the source. Source code can't lie (trusting trust notwithstanding).

> ignored my post about the symlink being confusing and error prone
> since the time it is read (before or after the chroot) is program
> dependent. It might even depend on options gives to a program when the
> first malloc call happens, making it even more unclear which symlink
> is being used.  Add the complexity with respect to unveil and pledge
> and it is clear why we replaced it. 

And I'm grateful. Having options - and such low-level options at
that! - encoded in such a weird way has always felt extremely
unopenbsd-like. This is another step toward sanity.

Simplicity! Thank you, devs.

Matthew



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Thomas Frohwein
On Sun, Apr 28, 2019 at 02:07:44AM +0700, Igor Podlesny wrote:
[...]
> Looks like decision made aren't subjects of discussing(?) Well, why
> the hell you have those mail lists then(?) :)

Igor:
The actual purpose of misc@ is for us to learn that you are among the people to
ignore.

Everyone else:
Move along, nothing to see here.



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread chohag
Igor Podlesny writes:
> On Sun, 28 Apr 2019 at 00:59,  wrote:
> [...]
> > >
> > > Oh, those hypocrite wankers here and there..
> >
> > If you actually read the code (I know, right? Who DOES that?) you'll see 
> > how omalloc_
> init perfectly embarrasses you. In 6.4 it would read the symlink, then 
> checked the envi
> ronment, and then consider the global variable malloc_options. In 6.5 it is 
> ... exactly
>  the same except that now sysctl is used instead of readlink (and hooray for 
> sanity).
> >
> > At no time was any attempt ever made by libc to force a programme to use 
> > only the set
> tings from sysctl née malloc.conf. If you had been using the environment 
> variable from 
> the beginning you would have been in _exactly_ the same position all that 
> time as you a
> re now. The security you think you've been relying on and have now lost was 
> never there
> . You have been protecting yourself with security theatre.
> >
> > Matthew
>
> Matthew, LOL, what?
> Read the code?
> You didn't even read the whole comment thread where I did explain that
> I was mostly concerned with cleared up environment other than changed
> options of that variable.

No, I did. I dismissed your arguments because they come from someone
who plainly has no idea what "the environment" even is.

malloc.c is quite lucid. Your continuing to spout off having clearly not
even glanced at it is a sorry state of affairs. But this is unix. We'll
continue to hand you as much rope as you like.

> Actually, I'd say that preparing chroots with malloc.conf as a symlink
> is more straightforward, more enforcing and easier to verify other
> than putting that as an environment option that would actually have to
> be read before target is running.

How in the ... Stay the hell away from my servers.

> And (of course) given with symlink
> it can't be so easily vanished when the whole environment is cleared
> up by user space.

/etc/malloc.conf can disappear exactly as easily as /etc/profile and
/etc/login.conf. More easily, in fact, if a tool to "handle" broken
symlinks gets involved.

> All-in-all, I didn't rely on this anyways.
> My question was purely theoretical and reaction was practically clumsy. :)

No, the reaction was dismissive of your complete lack of research and
understanding. Why should the developers or us other list members take
the time to read and understand the code you can't be arsed to?

In order to find out exactly how malloc handles its various
configuration sources took approximately 5 minutes of browsing on
cvsweb.openbsd.org to find the appropriate function and I don't even
know C that well. Your unwillingness to do even that is why you're being
treated with such derision.

> Looks like decision made aren't subjects of discussing(?) Well, why
> the hell you have those mail lists then(?) :)

Building something as large as OpenBSD simply cannot be done without
discussion so this is either a poor quality attempt at derision or
some sort of delusion. In fact I imagine that intellient discussion is
restricted to places where the general public are not permitted so that
it remain intelligent - for which I am most grateful. It's quite clear
why you've not been invited.

tl;dr: You don't understand and your ranting is just turning you into a
spectacle. Please do continue; I have popcorn.

Matthew



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Otto Moerbeek
On Sun, Apr 28, 2019 at 02:07:44AM +0700, Igor Podlesny wrote:

> On Sun, 28 Apr 2019 at 00:59,  wrote:
> [...]
> > >
> > > Oh, those hypocrite wankers here and there..
> >
> > If you actually read the code (I know, right? Who DOES that?) you'll see 
> > how omalloc_init perfectly embarrasses you. In 6.4 it would read the 
> > symlink, then checked the environment, and then consider the global 
> > variable malloc_options. In 6.5 it is ... exactly the same except that now 
> > sysctl is used instead of readlink (and hooray for sanity).
> >
> > At no time was any attempt ever made by libc to force a programme to use 
> > only the settings from sysctl née malloc.conf. If you had been using the 
> > environment variable from the beginning you would have been in _exactly_ 
> > the same position all that time as you are now. The security you think 
> > you've been relying on and have now lost was never there. You have been 
> > protecting yourself with security theatre.
> >
> > Matthew
> 
> Matthew, LOL, what?
> Read the code?
> You didn't even read the whole comment thread where I did explain that
> I was mostly concerned with cleared up environment other than changed
> options of that variable.
> 
> Actually, I'd say that preparing chroots with malloc.conf as a symlink
> is more straightforward, more enforcing and easier to verify other
> than putting that as an environment option that would actually have to
> be read before target is running. And (of course) given with symlink
> it can't be so easily vanished when the whole environment is cleared
> up by user space.
> 
> All-in-all, I didn't rely on this anyways.
> My question was purely theoretical and reaction was practically clumsy. :)
> Looks like decision made aren't subjects of discussing(?) Well, why
> the hell you have those mail lists then(?) :)
> For users to come and thank you and say you did all the best possible
> way only? :)
> To never question any decision? Seriously? No, really? C'mon, you
> gotta be kidding.
> 
> -- 
> End of message. Next message?
> 

The mechanism is in the docs as well, not only in the code. You
ignored my post about the symlink being confusing and error prone
since the time it is read (before or after the chroot) is program
dependent. It might even depend on options gives to a program when the
first malloc call happens, making it even more unclear which symlink
is being used.  Add the complexity with respect to unveil and pledge
and it is clear why we replaced it. 

-Otto






Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Igor Podlesny
On Sun, 28 Apr 2019 at 00:59,  wrote:
[...]
> >
> > Oh, those hypocrite wankers here and there..
>
> If you actually read the code (I know, right? Who DOES that?) you'll see how 
> omalloc_init perfectly embarrasses you. In 6.4 it would read the symlink, 
> then checked the environment, and then consider the global variable 
> malloc_options. In 6.5 it is ... exactly the same except that now sysctl is 
> used instead of readlink (and hooray for sanity).
>
> At no time was any attempt ever made by libc to force a programme to use only 
> the settings from sysctl née malloc.conf. If you had been using the 
> environment variable from the beginning you would have been in _exactly_ the 
> same position all that time as you are now. The security you think you've 
> been relying on and have now lost was never there. You have been protecting 
> yourself with security theatre.
>
> Matthew

Matthew, LOL, what?
Read the code?
You didn't even read the whole comment thread where I did explain that
I was mostly concerned with cleared up environment other than changed
options of that variable.

Actually, I'd say that preparing chroots with malloc.conf as a symlink
is more straightforward, more enforcing and easier to verify other
than putting that as an environment option that would actually have to
be read before target is running. And (of course) given with symlink
it can't be so easily vanished when the whole environment is cleared
up by user space.

All-in-all, I didn't rely on this anyways.
My question was purely theoretical and reaction was practically clumsy. :)
Looks like decision made aren't subjects of discussing(?) Well, why
the hell you have those mail lists then(?) :)
For users to come and thank you and say you did all the best possible
way only? :)
To never question any decision? Seriously? No, really? C'mon, you
gotta be kidding.

-- 
End of message. Next message?



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread chohag
Igor Podlesny writes:
> On Sat, 27 Apr 2019 at 18:09, Marc Espie  wrote:
> >
> > On Sat, Apr 27, 2019 at 12:34:01PM +0700, Igor Podlesny wrote:
> > > On Sat, 27 Apr 2019 at 12:26, Sebastien Marie  wrote:
> > > > On Sat, Apr 27, 2019 at 12:17:21PM +0700, Igor Podlesny wrote:
> > > > > Previously users could have different behaviour of malloc 
> > > > > simultaneously: one i
> n
> > > > > global FS, others in chroots. Say, in global it could be more relaxed
> > > [...]
> > > > malloc(3) man page mentions several ways to set malloc options:
> > > >
> > > > - globally with vm.malloc_conf sysctl(2)
> > > > - externally per apps with environment variable MALLOC_OPTIONS
> > > > - internally per apps with global variable malloc_options in the program
> > > >
> > > > So I suppose you want to look at exported MALLOC_OPTIONS environment
> > > > variable.
> > >
> > > Wrong. Environment is easy to be changed by any non-privileged process.
> > > OTOH, root owned /etc/malloc.conf is not.
> >
> > Man, you have some really strange delusions about how to harden things.
>
> %  man malloc.conf | grep -i security
>  S   Enable all options suitable for security auditing.
>
> Oh, those hypocrite wankers here and there..

If you actually read the code (I know, right? Who DOES that?) you'll see how 
omalloc_init perfectly embarrasses you. In 6.4 it would read the symlink, then 
checked the environment, and then consider the global variable malloc_options. 
In 6.5 it is ... exactly the same except that now sysctl is used instead of 
readlink (and hooray for sanity).

At no time was any attempt ever made by libc to force a programme to use only 
the settings from sysctl née malloc.conf. If you had been using the environment 
variable from the beginning you would have been in _exactly_ the same position 
all that time as you are now. The security you think you've been relying on and 
have now lost was never there. You have been protecting yourself with security 
theatre.

Matthew



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Igor Podlesny
On Sat, 27 Apr 2019 at 20:38, Vincent Legoll  wrote:
>
> On Sat, Apr 27, 2019 at 3:32 PM Igor Podlesny  wrote:
> > On Sat, 27 Apr 2019 at 18:09, Marc Espie  wrote:
> > > Man, you have some really strange delusions about how to harden things.
> >
> > %  man malloc.conf | grep -i security
> >  S   Enable all options suitable for security auditing.
> >
> > Oh, those hypocrite wankers here and there..
>
> Looks like auditing and hardening are not exactly the same thing.

And I didn't say "hardening". That's a delusion courtesy of Marc Espie
"the wako". ;-)

Although I can say "harder auditing" if you like. ;-)

-- 
End of message. Next message?



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Vincent Legoll
On Sat, Apr 27, 2019 at 3:32 PM Igor Podlesny  wrote:
> On Sat, 27 Apr 2019 at 18:09, Marc Espie  wrote:
> > Man, you have some really strange delusions about how to harden things.
>
> %  man malloc.conf | grep -i security
>  S   Enable all options suitable for security auditing.
>
> Oh, those hypocrite wankers here and there..

Looks like auditing and hardening are not exactly the same thing.

-- 
Vincent Legoll



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Igor Podlesny
On Sat, 27 Apr 2019 at 18:09, Marc Espie  wrote:
>
> On Sat, Apr 27, 2019 at 12:34:01PM +0700, Igor Podlesny wrote:
> > On Sat, 27 Apr 2019 at 12:26, Sebastien Marie  wrote:
> > > On Sat, Apr 27, 2019 at 12:17:21PM +0700, Igor Podlesny wrote:
> > > > Previously users could have different behaviour of malloc 
> > > > simultaneously: one in
> > > > global FS, others in chroots. Say, in global it could be more relaxed
> > [...]
> > > malloc(3) man page mentions several ways to set malloc options:
> > >
> > > - globally with vm.malloc_conf sysctl(2)
> > > - externally per apps with environment variable MALLOC_OPTIONS
> > > - internally per apps with global variable malloc_options in the program
> > >
> > > So I suppose you want to look at exported MALLOC_OPTIONS environment
> > > variable.
> >
> > Wrong. Environment is easy to be changed by any non-privileged process.
> > OTOH, root owned /etc/malloc.conf is not.
>
> Man, you have some really strange delusions about how to harden things.

%  man malloc.conf | grep -i security
 S   Enable all options suitable for security auditing.

Oh, those hypocrite wankers here and there..

-- 
End of message. Next message?



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Marc Espie
On Sat, Apr 27, 2019 at 12:34:01PM +0700, Igor Podlesny wrote:
> On Sat, 27 Apr 2019 at 12:26, Sebastien Marie  wrote:
> > On Sat, Apr 27, 2019 at 12:17:21PM +0700, Igor Podlesny wrote:
> > > Previously users could have different behaviour of malloc simultaneously: 
> > > one in
> > > global FS, others in chroots. Say, in global it could be more relaxed
> [...]
> > malloc(3) man page mentions several ways to set malloc options:
> >
> > - globally with vm.malloc_conf sysctl(2)
> > - externally per apps with environment variable MALLOC_OPTIONS
> > - internally per apps with global variable malloc_options in the program
> >
> > So I suppose you want to look at exported MALLOC_OPTIONS environment
> > variable.
> 
> Wrong. Environment is easy to be changed by any non-privileged process.
> OTOH, root owned /etc/malloc.conf is not.

Man, you have some really strange delusions about how to harden things.

I would suggest you go to another operating system. There are lots of wackos
out there with similar mixes of paranoia and wishful thinking.



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Kevin Chadwick
On 4/27/19 8:23 AM, Otto Moerbeek wrote:
> Additionally, in many cases using a symlink has unclear effects, since
> it is hard to determine if the first malloc call (malloc inits itself
> on first use) happens before of after the chroot call. I would argue
> that in many cases people were thinking they had per-chroot settings,
> while actually they had not.

Also, as Otto informed me on twitter, base is quite happy with the stronger
settings.

The code that really needs weaker settings inside the chroot, probably needs the
stronger settings the most, technically (if it didn't break). I like the more
convenient sysctl.

Be careful though, S cost me a couple of hours last night. After much success on
many systems without issue. I foolishly enabled S at the same time as PHP5 with
suhosin to php7 upgrade, All the statically built pledged parts, femail, PHP
output and reop, worked individually but femail would not send the mail when
directly sent from PHP. I still don't understand how malloc S could cause that
but turning back to the default, solved the breakage.

In any case, the inherent clarity of what is happening under the hood in golang
(php sh flags etc.) and the loss of php suhosin function whitelist feature
(again) that has avoided so many CVEs has affirmed moving to golang. Therefore,
I am not so bothered about finding why unless it helps OpenBSD somehow, which I
doubt?



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Consus
I like reading misc@ mostly due to the constanst BUTTHURT that is going
on here.

But seriously though, each program can change it's own malloc flags
either by calling setenv(3) or just by updating static malloc_options
variable. So there is really *NO* difference between your old way
(/etc/malloc.conf) and your new way (setenv MALLOC_OPTIONS). There is a
possibility that a program will reset it's own env, but it would most
likely not.



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Otto Moerbeek
On Fri, Apr 26, 2019 at 11:46:17PM -0600, Theo de Raadt wrote:

> Igor Podlesny  wrote:
> 
> > On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley  wrote:
> > >
> > > You didn't check the manpage.
> > 
> > you didn't think it over.
> > https://www.mail-archive.com/misc@openbsd.org/msg167012.html
> 
> No, you didn't think it through at all.
> 
> You are expecting the malloc settings to provide security gaurantees.
> They do not.  They detect corruption.  That is not the same as
> a security gaurantee.
> 
> Then you wish to use this inside a chroot jail, and make it tighter.
> 
> Fine.
> 
> Next you argue but what if the program inside the jail adjusts
> it's environment.  Well then all bets are off.  Why would that
> program modify it's environment variable only, rather than just
> doing anything else it wants to do?
> 
> Why would it restrict itself to adjusting this specific environment
> variable only, and why would you consider that to impact security?
> 
> 
> The malloc configuration was moved to a sysctl to make it compatible
> with pledge+unveil.  It has tightened the security in many programs.
> 
> The change has weakened security in your configurations because
> you designed them wrong.

Additionally, in many cases using a symlink has unclear effects, since
it is hard to determine if the first malloc call (malloc inits itself
on first use) happens before of after the chroot call. I would argue
that in many cases people were thinking they had per-chroot settings,
while actually they had not.

-Otto


> 
> Finally Igor you are being a jerk.  Cut it out.
> 



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Igor Podlesny
On Sat, 27 Apr 2019 at 12:55, Theo de Raadt  wrote:
> Igor Podlesny  wrote:
> > On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley  wrote:
> > > You didn't check the manpage.
> >
> > you didn't think it over.
> > https://www.mail-archive.com/misc@openbsd.org/msg167012.html
>
> Igor, talking back to the developers of the operating system you use is
> never a good idea.

Theo, if you can't read your mail list w/o losing your shit, don't
make it public.

-- 
End of message. Next message?



Re: Malloc config became global sysctl in 6.5

2019-04-26 Thread Igor Podlesny
> > Wrong. Environment is easy to be changed by any non-privileged process.
> > OTOH, root owned /etc/malloc.conf is not.
>
> Back then, when both /etc/malloc.conf and MALLOC_OPTIONS were set, which
> did a program prefer?

I'm more concerned with cleared up environment other than changed
MALLOC_OPTIONS.

>
> --
> Anthony J. Bentley



Re: Malloc config became global sysctl in 6.5

2019-04-26 Thread Theo de Raadt
Igor Podlesny  wrote:

> On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley  wrote:
> >
> > You didn't check the manpage.
> 
> you didn't think it over.
> https://www.mail-archive.com/misc@openbsd.org/msg167012.html

Igor, talking back to the developers of the operating system you use is
never a good idea.

There's this fine operating system that does exactly what you want -- it
is called OpenBSD 6.4, go ahead, use it.  You'll be happy.

For 6 months, lots of people worked on changes which make this system
better.  Thousands upon thousands of hours of work.

You were not one of those builders.

Yet a few days after release, you jump in to criticize our design
decisions, for software we primarily develop for ourselves -- in the
hope that other people are like us and need similar things.

We made decisions you don't understand because you haven't studied
the reasons.  You haven't read the commit messages.  You don't understand
our rationales, you only see your own point of view.

So you come off as a ranty jerk.

If you don't like our software, please don't use it.



Re: Malloc config became global sysctl in 6.5

2019-04-26 Thread Igor Podlesny
On Sat, 27 Apr 2019 at 12:46, Theo de Raadt  wrote:
> Igor Podlesny  wrote:
> > On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley  wrote:
> > > You didn't check the manpage.
> > you didn't think it over.
> > https://www.mail-archive.com/misc@openbsd.org/msg167012.html
>
> No, you didn't think it through at all.
>
> You are expecting

Now we enter that part were Theo becomes a medium.

> Then you wish to use this inside a chroot jail, and make it tighter.
>
> Fine.
> Next you argue but what if the program inside the jail adjusts
> it's environment.  Well then all bets are off.  Why would that
> program modify it's environment variable only, rather than just
> doing anything else it wants to do?

Because any user space daemon can clear up its own environment
completely and put a big bold dick onto your malloc options, Theo.

> Why would it restrict itself to adjusting this specific environment
> variable only, and why would you consider that to impact security?
>
>
> The malloc configuration was moved to a sysctl to make it compatible
> with pledge+unveil.  It has tightened the security in many programs.
>
> The change has weakened security in your configurations because
> you designed them wrong.
>
> Finally Igor you are being a jerk.  Cut it out.

Very jerk-like sounding. Cut it out, Theo. But it's obvious you can't. Nature...

-- 
End of message. Next message?



Re: Malloc config became global sysctl in 6.5

2019-04-26 Thread Theo de Raadt
Igor Podlesny  wrote:

> On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley  wrote:
> >
> > You didn't check the manpage.
> 
> you didn't think it over.
> https://www.mail-archive.com/misc@openbsd.org/msg167012.html

No, you didn't think it through at all.

You are expecting the malloc settings to provide security gaurantees.
They do not.  They detect corruption.  That is not the same as
a security gaurantee.

Then you wish to use this inside a chroot jail, and make it tighter.

Fine.

Next you argue but what if the program inside the jail adjusts
it's environment.  Well then all bets are off.  Why would that
program modify it's environment variable only, rather than just
doing anything else it wants to do?

Why would it restrict itself to adjusting this specific environment
variable only, and why would you consider that to impact security?


The malloc configuration was moved to a sysctl to make it compatible
with pledge+unveil.  It has tightened the security in many programs.

The change has weakened security in your configurations because
you designed them wrong.

Finally Igor you are being a jerk.  Cut it out.



Re: Malloc config became global sysctl in 6.5

2019-04-26 Thread Anthony J. Bentley
Igor Podlesny writes:
> On Sat, 27 Apr 2019 at 12:26, Sebastien Marie  wrote:
> > On Sat, Apr 27, 2019 at 12:17:21PM +0700, Igor Podlesny wrote:
> > > Previously users could have different behaviour of malloc simultaneously:
>  one in
> > > global FS, others in chroots. Say, in global it could be more relaxed
> [...]
> > malloc(3) man page mentions several ways to set malloc options:
> >
> > - globally with vm.malloc_conf sysctl(2)
> > - externally per apps with environment variable MALLOC_OPTIONS
> > - internally per apps with global variable malloc_options in the program
> >
> > So I suppose you want to look at exported MALLOC_OPTIONS environment
> > variable.
>
> Wrong. Environment is easy to be changed by any non-privileged process.
> OTOH, root owned /etc/malloc.conf is not.

Back then, when both /etc/malloc.conf and MALLOC_OPTIONS were set, which
did a program prefer?

-- 
Anthony J. Bentley



Re: Malloc config became global sysctl in 6.5

2019-04-26 Thread Igor Podlesny
On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley  wrote:
>
> You didn't check the manpage.

you didn't think it over.
https://www.mail-archive.com/misc@openbsd.org/msg167012.html

-- 
End of message. Next message?



Re: Malloc config became global sysctl in 6.5

2019-04-26 Thread Anthony J. Bentley
Igor Podlesny writes:
> Previously users could have different behaviour of malloc simultaneously: one
>  in
> global FS, others in chroots. Say, in global it could be more relaxed
> with lesser
> performance impact and in some chroots more drastic, at contrary. With
> 6.5 it's not
> possible anymore, is it really so? This change has own pluses as well
> indeed: one
> knob to rule them all but then what if you need something special in
> just one place,
> something that shouldn't be following global sysctl parameters -- how
> do you get it(?)

You didn't check the manpage.

 Upon the first call to the malloc() family of functions, an
 initialization sequence inspects the value of the vm.malloc_conf
 sysctl(2), next checks the environment for a variable called
 MALLOC_OPTIONS, and finally looks at the global variable malloc_options
 in the program.

-- 
Anthony J. Bentley



Re: Malloc config became global sysctl in 6.5

2019-04-26 Thread Igor Podlesny
On Sat, 27 Apr 2019 at 12:26, Sebastien Marie  wrote:
> On Sat, Apr 27, 2019 at 12:17:21PM +0700, Igor Podlesny wrote:
> > Previously users could have different behaviour of malloc simultaneously: 
> > one in
> > global FS, others in chroots. Say, in global it could be more relaxed
[...]
> malloc(3) man page mentions several ways to set malloc options:
>
> - globally with vm.malloc_conf sysctl(2)
> - externally per apps with environment variable MALLOC_OPTIONS
> - internally per apps with global variable malloc_options in the program
>
> So I suppose you want to look at exported MALLOC_OPTIONS environment
> variable.

Wrong. Environment is easy to be changed by any non-privileged process.
OTOH, root owned /etc/malloc.conf is not.

-- 
End of message. Next message?



Re: Malloc config became global sysctl in 6.5

2019-04-26 Thread Sebastien Marie
On Sat, Apr 27, 2019 at 12:17:21PM +0700, Igor Podlesny wrote:
> Previously users could have different behaviour of malloc simultaneously: one 
> in
> global FS, others in chroots. Say, in global it could be more relaxed
> with lesser
> performance impact and in some chroots more drastic, at contrary. With
> 6.5 it's not
> possible anymore, is it really so? This change has own pluses as well
> indeed: one
> knob to rule them all but then what if you need something special in
> just one place,
> something that shouldn't be following global sysctl parameters -- how
> do you get it(?)
 
malloc(3) man page mentions several ways to set malloc options:

- globally with vm.malloc_conf sysctl(2)
- externally per apps with environment variable MALLOC_OPTIONS
- internally per apps with global variable malloc_options in the program

So I suppose you want to look at exported MALLOC_OPTIONS environment
variable.

Thanks.
-- 
Sebastien Marie