Don't setenv in multi-threaded code on glibc

Re:Don't setenv in multi-threaded code on glibc by masklinn on Tuesday January 31, 2017 @09:35AM (#13530830)

> Because as anyone doing POSIX development across multiple OS learns, that is an implementation detail.

The problem is the interface is naturally unsafe. Much like e.g. strcpy, the interface means it's nigh impossible to use it safely.

[ Parent | on HN ]

Re:Don't setenv in multi-threaded code on glibc by pjmlp on Tuesday January 31, 2017 @01:04PM (#13533314)

Which is the reason that even if we would write an UNIX OS in something like Ada or Rust instead of C, we wouldn't get away from security exploits caused by the UNIX API.

Hence why in parallel with better systems languages, we really need tagged architectures for pointers, like what SPARC V8, Intel MPX, Cherry offer, to become widespread, for better security.

[ Parent | on HN ]

Re:Don't setenv in multi-threaded code on glibc by quotemstr on Tuesday January 31, 2017 @01:11PM (#13533392)

Upthread, I pointed out a sane and safe alternative to POSIX getenv interface, one that works fine with regular C, and here, you're claiming that we need exotic features to achieve safety? What?

[ Parent | on HN ]

Re:Don't setenv in multi-threaded code on glibc by pjmlp on Tuesday January 31, 2017 @03:08PM (#13534712)

Because you only focused on getenv.

I was replying about the whole UNIX API surface, regarding functions like strcpy.

You need exotic features to guarantee that the memory doesn't get corrupted.

[ Parent | on HN ]