12 ms·

Windows has sane environment-retrieval functions: https://msdn.microsoft.com/en-us/library/windows/desktop/ms683188(v=vs.85).aspx https://msdn.microsoft.com/en-

Windows has sane environment-retrieval functions: https://msdn.microsoft.com/en-us/library/windows/desktop/ms683188(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6... Unlike getenv, GetEnvironmentVariable copies a variable's value into a caller provided buffer, addressing the use-after-free problem inherent in getenv's interface. Wouldn't it be nice if glibc got something like a getenv2 with a similar interface? Why should people have to trip over weird corner cases in POSIX over and over and over again? Why are we afraid to add new APIs that make some damn sense?

Sanddancer 10y ago
This is a pure glibcism. FreeBSD libc does similar with getenv, in that the returned environment is a snapshot of that point in time.
- simias 10y ago
  IMO getenv's API itself is to blame since it won't let you provide a buffer. As such if the libc wants to provide a local buffer it has to figure out a way to allocate it for the caller. As far as I can tell glibc's implementation is probably what the people who designed getenv in the first place had in mind, just return a pointer to a global buffer. At best FreeBSD managed to create a workaround for modern environments. There are unfortunately many such oddities in the standard libc APIs, remnants from an other time. Let us remember that "gets" was standardized as part of the C standard at some point, a function that's by design literally impossible to use safely.
  - cesarb 10y ago
    > Let us remember that "gets" was standardized as part of the C standard at some point, a function that's by design literally impossible to use safely. It _is_ possible in theory to use gets safely, as long as your standard input is trusted. For instance, if a process forks and connects the standard input in the child to a pipe from the parent, which always writes a fixed amount of data to the pipe, you can use gets() without risk of overflow. (This is a really contrived scenario, but I don't know of any simpler one where using gets() is safe.)
    - MaulingMonkey 10y ago
      > It _is_ possible in theory to use gets safely, as long as your standard input is trusted. Only if we define "trusted" to include "known to be bug free" in e.g. it's truncation or bounding of output over the pipe to the child. I argue that, in theory, this is impossible to know, and thus that it this level of trust is impossible, and thus that this is not an example of a potential safe use of gets. Even a mathematical proof of safety, after all, could contain errors - or could prove the wrong thing - or could apply to the code as written and not the code as messed with by your optimizer - or another thread - or an injected dll - or ... > For instance, if a process forks and connects the standard input in the child to a pipe from the parent, which always writes a fixed amount of data to the pipe, you can use gets() without risk of overflow. This is also insufficient - one must also prevent nonstandard invocations of the child process. Even if your normal parent process gives the child input that is 100% safe, that's no guarantee that an attacker won't launch your child process in an unusual manner. If the child process is suid, for example, this would be a potential avenue for privilege escalation.
      - cesarb 10y ago
        > Only if we define "trusted" to include "known to be bug free" in e.g. it's truncation or bounding of output over the pipe to the child. I argue that, in theory, this is impossible to know, and thus that it this level of trust is impossible, and thus that this is not an example of a potential safe use of gets. "In the security engineering subspecialty of computer science, a trusted system is a system that is relied upon to a specified extent to enforce a specified security policy. As such, a trusted system is one whose failure may break a specified security policy." -- https://en.wikipedia.org/wiki/Trusted_system https://en.wikipedia.org/wiki/Trusted_system That's the definition of "trusted" I'm using. > This is also insufficient - one must also prevent nonstandard invocations of the child process. I'm thinking of pure fork(), not fork+exec. That is, the child process is the same executable image, so the only way to invoke the child process in a nonstandard way would be through a debugger. And that is why the child process can trust the parent process in my example: they're the same process until the fork(). (As I said, it's a really contrived scenario. In more realistic scenarios, gets() is unsafe.)
  - pjmlp 10y ago
    > Let us remember that "gets" was standardized as part of the C standard at some point, a function that's by design literally impossible to use safely. Which thankfully was removed by recent standard revisions of C and C++, meaning a compliant compiler isn't required to provide it any longer.
  - exprA 10y ago
    gets is impossible to use safely with unformatted input, which need not be the case.
  - JdeBP 10y ago
    Actually, what we should remember is that setenv, clearenv, unsetenv, and putenv came along a lot later than getenv. There was a fair while when the general mental model was that the environment was immutable.
- bonzini 10y ago
  That is irrelevant. FreeBSD getenv doesn't protect accesses to the event with a lock, meaning that getenv will access a freed copy of the environment if a concurrent call to putenv resizes the underlying array. Musl has the same issue.
  - Sanddancer 10y ago
    It uses a lock-free method of ensuring that there aren't segfaults. When it needs to move a variable because it's gotten too big, it copies it to the new location and sets the pointer accordingly with the old location flagged as old. The old variable isn't freed, so there are no dangling pointers, with the downside of memory usage being increased some.
    - bonzini 10y ago
      Doesn't it just use realloc? See __rebuild_environ in https://github.com/freebsd/freebsd/blob/master/lib/libc/stdlib/getenv.c https://github.com/freebsd/freebsd/blob/master/lib/libc/stdl...
- deathanatos 10y ago
  > FreeBSD libc does similar with getenv, in that the returned environment is a snapshot of that point in time. How does FreeBSD's libc know when to free that snapshot? (Since there is no "free the env snapshot you gave me" call.) If thread B calls getenv, how does that not invalidate the snapshot that thread A has?
  - MaulingMonkey 10y ago
    Thread local storage would let you store a snapshot for thread A until thread A itself re-invokes getenv. Other comments seem to imply this isn't what FreeBSD is doing however.
    - quotemstr 10y ago
      So what if you call getenv twice? const char* foo = getenv("FOO"); const char* bar = getenv("BAR"); foo and bar should both be valid here. Sure, you could allocate an arbitrary amount of thread-local storage, but that's still a leak.
      - MaulingMonkey 10y ago
        Guess there's a reason FreeBSD isn't doing it :D.
pjmlp 10y ago
Because as anyone doing POSIX development across multiple OS learns, that is an implementation detail. POSIX like any other paper standard implies write once debug everywhere.
- masklinn 10y ago
  > 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.
  - pjmlp 10y ago
    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.
    - quotemstr 10y ago
      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?
      - pjmlp 10y ago
        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.
- tedunangst 10y ago
  The posix standard explicitly says setenv is not thread safe. This shouldn't be a mystery.
deleted 10y ago
[deleted]
theamk 10y ago
Agree. We have strerror_r -- why not add getenv_r?
- quotemstr 10y ago
  I'd go write a getenv_r myself right now, but my gut feeling is that the glibc people would reject the patch on the basis that POSIX says that getenv is unsafe, we get along without a getenv_r, and therefore we don't need a getenv_r. This is why we can't have nice things.
  - alyandon 10y ago
    I don't know why you are getting downvotes. Someone tried to propose a getenv_r implementation for glibc in 2007 and even submitted a patch - which was rejected by a certain someone that is pretty famous for not wanting "bsd crap" in glibc. https://sourceware.org/bugzilla/show_bug.cgi?id=4350 https://sourceware.org/bugzilla/show_bug.cgi?id=4350
    - viraptor 10y ago
      Since he left, some old ideas have been raised again and merged. It could be worth revisiting.
      - alyandon 10y ago
        Ah, that's right he did move on. :)
yuhong 10y ago
This reminds me of GetEnvironmentStringsW, which used to return the pointer directly but was eventually changed (I think in Vista) to copy.
JdeBP 10y ago
> Why are we afraid to add new APIs that make some damn sense? Speak for yourself. I implemented a Standard C library which guarded the environment, and various other global variables that the language requires that the library have, with mutexes. I did this in the early 1990s. I am far from alone, as far as C library implementors go. Your "we" is actually a small number of people.

Sanddancer 10y ago

This is a pure glibcism. FreeBSD libc does similar with getenv, in that the returned environment is a snapshot of that point in time.

simias 10y ago
IMO getenv's API itself is to blame since it won't let you provide a buffer. As such if the libc wants to provide a local buffer it has to figure out a way to allocate it for the caller. As far as I can tell glibc's implementation is probably what the people who designed getenv in the first place had in mind, just return a pointer to a global buffer. At best FreeBSD managed to create a workaround for modern environments. There are unfortunately many such oddities in the standard libc APIs, remnants from an other time. Let us remember that "gets" was standardized as part of the C standard at some point, a function that's by design literally impossible to use safely.
- cesarb 10y ago
  > Let us remember that "gets" was standardized as part of the C standard at some point, a function that's by design literally impossible to use safely. It _is_ possible in theory to use gets safely, as long as your standard input is trusted. For instance, if a process forks and connects the standard input in the child to a pipe from the parent, which always writes a fixed amount of data to the pipe, you can use gets() without risk of overflow. (This is a really contrived scenario, but I don't know of any simpler one where using gets() is safe.)
  - MaulingMonkey 10y ago
    > It _is_ possible in theory to use gets safely, as long as your standard input is trusted. Only if we define "trusted" to include "known to be bug free" in e.g. it's truncation or bounding of output over the pipe to the child. I argue that, in theory, this is impossible to know, and thus that it this level of trust is impossible, and thus that this is not an example of a potential safe use of gets. Even a mathematical proof of safety, after all, could contain errors - or could prove the wrong thing - or could apply to the code as written and not the code as messed with by your optimizer - or another thread - or an injected dll - or ... > For instance, if a process forks and connects the standard input in the child to a pipe from the parent, which always writes a fixed amount of data to the pipe, you can use gets() without risk of overflow. This is also insufficient - one must also prevent nonstandard invocations of the child process. Even if your normal parent process gives the child input that is 100% safe, that's no guarantee that an attacker won't launch your child process in an unusual manner. If the child process is suid, for example, this would be a potential avenue for privilege escalation.
    - cesarb 10y ago
      > Only if we define "trusted" to include "known to be bug free" in e.g. it's truncation or bounding of output over the pipe to the child. I argue that, in theory, this is impossible to know, and thus that it this level of trust is impossible, and thus that this is not an example of a potential safe use of gets. "In the security engineering subspecialty of computer science, a trusted system is a system that is relied upon to a specified extent to enforce a specified security policy. As such, a trusted system is one whose failure may break a specified security policy." -- https://en.wikipedia.org/wiki/Trusted_system https://en.wikipedia.org/wiki/Trusted_system That's the definition of "trusted" I'm using. > This is also insufficient - one must also prevent nonstandard invocations of the child process. I'm thinking of pure fork(), not fork+exec. That is, the child process is the same executable image, so the only way to invoke the child process in a nonstandard way would be through a debugger. And that is why the child process can trust the parent process in my example: they're the same process until the fork(). (As I said, it's a really contrived scenario. In more realistic scenarios, gets() is unsafe.)
- pjmlp 10y ago
  > Let us remember that "gets" was standardized as part of the C standard at some point, a function that's by design literally impossible to use safely. Which thankfully was removed by recent standard revisions of C and C++, meaning a compliant compiler isn't required to provide it any longer.
- exprA 10y ago
  gets is impossible to use safely with unformatted input, which need not be the case.
- JdeBP 10y ago
  Actually, what we should remember is that setenv, clearenv, unsetenv, and putenv came along a lot later than getenv. There was a fair while when the general mental model was that the environment was immutable.
bonzini 10y ago
That is irrelevant. FreeBSD getenv doesn't protect accesses to the event with a lock, meaning that getenv will access a freed copy of the environment if a concurrent call to putenv resizes the underlying array. Musl has the same issue.
- Sanddancer 10y ago
  It uses a lock-free method of ensuring that there aren't segfaults. When it needs to move a variable because it's gotten too big, it copies it to the new location and sets the pointer accordingly with the old location flagged as old. The old variable isn't freed, so there are no dangling pointers, with the downside of memory usage being increased some.
  - bonzini 10y ago
    Doesn't it just use realloc? See __rebuild_environ in https://github.com/freebsd/freebsd/blob/master/lib/libc/stdlib/getenv.c https://github.com/freebsd/freebsd/blob/master/lib/libc/stdl...
deathanatos 10y ago
> FreeBSD libc does similar with getenv, in that the returned environment is a snapshot of that point in time. How does FreeBSD's libc know when to free that snapshot? (Since there is no "free the env snapshot you gave me" call.) If thread B calls getenv, how does that not invalidate the snapshot that thread A has?
- MaulingMonkey 10y ago
  Thread local storage would let you store a snapshot for thread A until thread A itself re-invokes getenv. Other comments seem to imply this isn't what FreeBSD is doing however.
  - quotemstr 10y ago
    So what if you call getenv twice? const char* foo = getenv("FOO"); const char* bar = getenv("BAR"); foo and bar should both be valid here. Sure, you could allocate an arbitrary amount of thread-local storage, but that's still a leak.
    - MaulingMonkey 10y ago
      Guess there's a reason FreeBSD isn't doing it :D.

pjmlp 10y ago

Because as anyone doing POSIX development across multiple OS learns, that is an implementation detail. POSIX like any other paper standard implies write once debug everywhere.

masklinn 10y ago
> 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.
- pjmlp 10y ago
  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.
  - quotemstr 10y ago
    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?
    - pjmlp 10y ago
      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.
tedunangst 10y ago
The posix standard explicitly says setenv is not thread safe. This shouldn't be a mystery.

deleted 10y ago

[deleted]

theamk 10y ago

Agree. We have strerror_r -- why not add getenv_r?

quotemstr 10y ago
I'd go write a getenv_r myself right now, but my gut feeling is that the glibc people would reject the patch on the basis that POSIX says that getenv is unsafe, we get along without a getenv_r, and therefore we don't need a getenv_r. This is why we can't have nice things.
- alyandon 10y ago
  I don't know why you are getting downvotes. Someone tried to propose a getenv_r implementation for glibc in 2007 and even submitted a patch - which was rejected by a certain someone that is pretty famous for not wanting "bsd crap" in glibc. https://sourceware.org/bugzilla/show_bug.cgi?id=4350 https://sourceware.org/bugzilla/show_bug.cgi?id=4350
  - viraptor 10y ago
    Since he left, some old ideas have been raised again and merged. It could be worth revisiting.
    - alyandon 10y ago
      Ah, that's right he did move on. :)

yuhong 10y ago

This reminds me of GetEnvironmentStringsW, which used to return the pointer directly but was eventually changed (I think in Vista) to copy.

JdeBP 10y ago

> Why are we afraid to add new APIs that make some damn sense? Speak for yourself. I implemented a Standard C library which guarded the environment, and various other global variables that the language requires that the library have, with mutexes. I did this in the early 1990s. I am far from alone, as far as C library implementors go. Your "we" is actually a small number of people.