Red Hat Bugzilla – Bug 154126
Insecure world-readable log file creation in /tmp when debug=1
Last modified: 2013-07-02 23:05:29 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Firefox/1.0.2 Fedora/1.0.2-3
Description of problem:
unixODBC, at least with the postgresql driver (I haven't tried other drivers), creates insecure log files in /tmp when the debug=1 option is set in odbc.ini.
1. They contain passwords
2. They are world-readable(!)
3. Their filenames are predictable (mkstemp not used, apparently).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install a program that uses ODBC.
2. Put debug=1 in /etc/odbc.ini
3. Restart the program that uses ODBC (in my case, "service ldap restart").
Actual Results: A log file appears in /tmp, like this:
-rw-r--r-- 1 ldap ldap 197307 Apr 7 17:46 mylog_ldap14229.log
It contains the database password in the first few lines. 14229 is the pid of one of the ldap server processes (slapd), and this is not just a coincidence - log filenames are always generated from the pid.
Expected Results: Either it should refuse to create a log file unless an explicit filename is given, or else I think it should use mkstemp (but still keep the pid in the filename for identification purposes) and set the permissions to -rw-------.
Not sure if this bug is in unixODBC or postgresql.
*** Bug 154128 has been marked as a duplicate of this bug. ***
Actually I'd blame it on postgresql-odbc. There is a very old version of the PG ODBC driver in the
unixODBC package, from which we can see that the problem is of long standing ... but I'm not going to
fix that, rather remove it. If anything is to be done about this it'll be in postgresql-odbc.
I'll take the question up with the upstream postgresql-odbc maintainers. Since it's acted like this for so
long, it seems possible that the behavior is intentional, though I agree that sticking a password into
such a file doesn't sound like a hot idea.
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.
This is a security bug so reassigning to Fedora Legacy as directed.
For some reason this stayed in NEEDINFO state - trying again.
Tom, have you heard anything from upstream on this issue?
Closing Fedora Legacy bugs.