*Why* does Progress set TMPDIR to unknown when you start a session?
export TMPDIR=xyzzy
pro
display os-getenv( "TMPDIR" ).
?
Ok, I found something more definite: www.win.tue.nl/.../hh-8.html
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.
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.
OpenEdge Release 11.7.2 as of Tue Oct 24 18:20:59 EDT 2017
# echo $SHELL
/bin/bash
or
# echo $SHELL
/bin/sh
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, 11.6.3.017, 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.
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.
knowledgebase.progress.com/.../P71053
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?
I don't *remember* previously reporting it. But that doesn't mean much ;)
> 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).
https://knowledgebase.progress.com/articles/Article/21552
"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?
[quote user="Stefan Drissen"]
knowledgebase.progress.com/.../P71053
The exclamation mark could indicate that you have raised this question with tech support before ;-)
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?
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.
www.gnu.org/.../Temporary-Files.html
"The environment variable TMPDIR, if it is defined. For security reasons this only happens if the program is not SUID or SGID enabled."
tempnam(3) - Linux man page
https://linux.die.net/man/3/tempnam
"SUSv2 does not mention the use of TMPDIR; glibc will use it only when the program is not set-user-ID."
That says that the checking of the TMPDIR variable won't happen if the program is not SUID or GUID -- not that the variable itself is going to be clobbered.
Also it is talking very specifically about a process for creating temp files -- not a general clobbering of the variable.
I'm becoming obsessed by this ;)
Ok, I found something more definite: www.win.tue.nl/.../hh-8.html
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.
And as with all great software issues, this is a documentation issue :-)
[quote user="ChUIMonster"]
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?
Awesome!