Igor Podlesny writes: > On Sat, 27 Apr 2019 at 18:09, Marc Espie <es...@nerim.net> wrote: > > > > On Sat, Apr 27, 2019 at 12:34:01PM +0700, Igor Podlesny wrote: > > > On Sat, 27 Apr 2019 at 12:26, Sebastien Marie <sema...@online.fr> 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
