TMPDIR environment variable - Forum - OpenEdge General - Progress Community

TMPDIR environment variable


TMPDIR environment variable

This question is answered

*Why* does Progress set TMPDIR to unknown when you start a session?

export TMPDIR=xyzzy


display os-getenv( "TMPDIR" ).


Tom Bascom

Verified Answer
  • Ok, I found something more definite:

    8.10 Setuid binaries

    As a security measure, the glibc library will return NULL for certain environment variables that influence the semantics of certain libc functions, when used from a setuid binary. For glibc 2.2.5-2.3.2 the list is LD_AOUT_LIBRARY_PATH, LD_AOUT_PRELOAD, LD_LIBRARY_PATH, LD_PRELOAD, LD_ORIGIN_PATH, LD_DEBUG_OUTPUT, LD_PROFILE, GCONV_PATH, HOSTALIASES, LOCALDOMAIN, LOCPATH, MALLOC_TRACE, NLSPATH, RESOLV_HOST_CONF, RES_OPTIONS, TMPDIR, TZDIR. Glibc 2.3.3 adds LD_USE_LOAD_BIAS. Glibc 2.3.4 adds LD_DEBUG, LD_DYNAMIC_WEAK, LD_SHOW_AUXV, GETCONF_DIR. (Pity! LD_DEBUG was so useful in winning races. But the idea of throttling error message output via a pipe is still useful.) Glibc 2.4 adds LD_AUDIT. Glibc 2.5.1 adds NIS_PATH. Also MALLOC_CHECK_ is removed, unless /etc/suid-debug exists.

    Tom Bascom

All Replies
  • I got the value I set on OS level. Tested with Progress 11.7 on Linux and Windows.

  • I tried again.  Very carefully.  With 11.7.2 and I am still getting ? :(

    Running _progres results in the same behavior as pro.

    Could it be some obscure shell setting?  I'm just using plain old /bin/bash on Amazon Linux but I have the same problem on an old SUSE and with OE10.2 so I don't think it is Progress or Linux version specific.

    Tom Bascom

  • OpenEdge Release 11.7.2 as of Tue Oct 24 18:20:59 EDT 2017

    # echo $SHELL



    # echo $SHELL


    display os-getenv( "TMPDIR" ). => xyzzy

    'strings $DLC/bin/_progres | grep TMPDIR' returns nothing

  • Odd.  I get a mix of both results.

    On Centos 6.9, bash 4.1.2(2), OE 11.6.0,, and 11.7.3, the value of $TMPDIR is preserved.

    On RHEL 6.3, bash 4.1.2(1), OE 10.2B, 11.3.2, 11.4, 11.6.3, $TMPDIR is unknown.

    On SLES 11.1, bash 3.2.51(1), OE 11.6.3, $TMPDIR is unknown.

    On Centos 6.6, bash 4.1.2(1), OE 11.6.3, $TMPDIR is unknown.

    It appears there is no difference in behaviour between pro and _progres.

    The only reference I find to TMPDIR in the installation manual is under the -l parameter for the proinst silent install.

  • That suggests that it is something about the environment rather than Progress.  Interesting.

    Tom Bascom

  • I don't see in the source any code which sets the TMPDIR environment variable, and only a few utilities (mostly on Windows) which read it.


    The exclamation mark could indicate that you have raised this question with tech support before ;-)

  • Makes sense.  So it seems the issue is the user's security context.  On my sandbox machine (CentOS 6.9) I was already root when I set the env vars, so they were preserved in the _progres environment.  On the other machines I was logged in as myself (non-root) so there was a change of security context.  

  • But why does it only impact TMPDIR?

    Tom Bascom

  • I don't *remember* previously reporting it.  But that doesn't mean much ;)

    Tom Bascom

  • > But why does it only impact TMPDIR?

    LD_LIBRARY_PATH on Linux has the same affect (and SHLIB_PATH on HPUX or LIBPATH on AIX, I guess).

    "This is because some OS have a security mechanism implemented that only allows root to load shared libraries from the /usr/lib directory."

  • Ok, I guess I sort of follow along with the idea that similar issues might apparently have something to do with setting the setuid bit but what does any of that have to do with TMPDIR?  And why on some platforms but not on others?

    If this issue can randomly impact TMPDIR what other environment variables are on the "risky" list?

    Tom Bascom

  • Stefan Drissen

    The exclamation mark could indicate that you have raised this question with tech support before ;-)

    Bug OE00101832, which is referenced in this KB article, has detailed information about the issue. Below is what Mike Furgal wrote when closing the bug (14 years ago!). He wrote a C program which retrieves the value of TMPDIR. He made two versions of the program - one that runs as a normal user and one that runs as root. The normal version can see TMPDIR and the root version can't.
    I have narrowed this down to the following C program:
    #include <stdlib.h>
    int argc;
    char *argv[];
        char *p = (char *)0;
        p = getenv(argv[1]);
        if (p == (char *)0)
            printf("%s not set\n",argv[1]);
            printf("%s = %s\n",argv[1],p);

    When this is compile using the following steps
    # gcc -o getenv getenv.c
    # cp getenv rootgetenv
    # su
    root# chown root rootgetenv
    root# chmod u+s rootgentenv
    root# exit
    # ls -l 
    total 36
    -rwxrwxr-x    1 mikef    rdl         13919 Mar 11 09:46 getenv
    -rw-rw-r--    1 mikef    rdl           253 Mar 11 09:44 getenv.c
    -rwsrwxr-x    1 root     rdl         13919 Mar 11 09:44 rootgetenv
    # TMPDIR=/usr1/100a/wrk/mikef/tmp; export TMPDIR
    # echo $TMPDIR
    # ./getenv TMPDIR
    TMPDIR = /usr1/100a/wrk/mikef/tmp
    # ./rootgetenv TMPDIR
    TMPDIR not set

    However if I use a different variable it works fine.  This is tied specifically to the TMPDIR environment variable.

    Also, when I su on the machine I notice that my TMPDIR environment setting is gone while other environment variable settings remain.

    $TMPDIR is used in many Unlx/Linux commands and system calls, so it looks to me like a security hole was closed by making root processes lose the setting.  Most other environment variables are retained across a setuid() boundary.
  • If I might be so bold... perhaps the special behavior of TMPDIR might be worthy of mentioning in the "Notes" section of the OS-GETENV statement?

    Tom Bascom

  • Clearly Progress is not at fault here -- but I remain curious where this behavior is documented in any of the rest of the world.  My attempts to find anything about this from a generic UNIX perspective via Google were fruitless.

    Tom Bascom