postfix bug: SuSEconfig.postfix runs arbitrary command, and/or fails but returns success code
I've found a bug that causes SuSEconfig (and, presumably, Yast2, since it uses SuSEconfig) to fail to update Postfix configuration and then incorrectly report that it has done so successfully. More alarmingly, if any command `postconf' exists in a user's PATH when running the SuSEconfig postfix module, *that command*, (whichever one is found first; not necessarily the intended one) will be run by SuSEconfig. Worse yet, if SuSEconfig is run with superuser privileges (which is the only way it will work properly) then this arbitrary postconf command is executed with superuser privileges, and SuSEconfig will prepend any output from the command to /etc/postfix/main.cf. Scripts that execute a command without specifying the path to that command, *especially* those which are likely to be run as root, are extremely bad policy; surely this is an oversight on SuSE's part. Keyword and full-text searches of the SuSE support database for `postfix' result in no relevant information. I'm unable to find any mention of this bug on the Web. Concise description: In the SuSE Linux 9.0 Postfix package, version 2.0.14, release 54 (postfix-2.0.14-54.rpm), the SuSEconfig postfix module (/sbin/conf.d/SuSEconfig.postfix) incorrectly assumes that the command `postconf' will be found in its path (i.e., it assumes that /usr/sbin is in the PATH environment variable of the user executing SuSEconfig). It will execute the first executable file named `postconf' found in the users search path, and prepend any output to /etc/postfix/main.cf. Workaround: Manually ensure that Postfix's postconf command is the first postconf found in your search path for commands (i.e., examine the output of `which postconf' and adjust your PATH environment variable if necessary before running SuSEconfig). As of the current version (2.0.14-54) of SuSE's Postfix package, postconf is installed in /usr/sbin, so simply prepending /usr/sbin to your PATH before running SuSEconfig works for now, but there is no guarantee that this will not change in future releases, so this workaround cannot be relied upon after the next upgrade of postfix. Suggested fix: SuSE modifies its postfix package such that /sbin/conf.d/SuSEconfig.postfix does the following: * uses absolute path for any commands which it will execute * exits with a return code truly indicative of whether or not it completed successfully Details (plain text) of how to reproduce the error, as I submitted to SuSE, are attached as suse_postfix_suseconfig_bug. -- Phil Mocek
On Wednesday 14 April 2004 00.07, Phil Mocek wrote:
I've found a bug that causes SuSEconfig (and, presumably, Yast2, since it uses SuSEconfig) to fail to update Postfix configuration and then incorrectly report that it has done so successfully.
More alarmingly, if any command `postconf' exists in a user's PATH when running the SuSEconfig postfix module, *that command*, (whichever one is found first; not necessarily the intended one) will be run by SuSEconfig.
I think it goes without saying that you should never have a user writable directory in your path when you run things as root. There are lots of programs being executed in all the SuSEconfig scripts without a full path, such as cat or sed or ps. If someone has dropped a binary in $HOME/bin and that is first in your path, you're cooked. I think the real bug is that SuSEconfig doesn't reset the path to something sane.
On Wed, Apr 14, 2004 at 01:17:14AM +0200, Anders Johansson wrote:
On Wednesday 14 April 2004 00.07, Phil Mocek wrote:
I've found a bug that causes SuSEconfig (and, presumably, Yast2, since it uses SuSEconfig) to fail to update Postfix configuration and then incorrectly report that it has done so successfully.
More alarmingly, if any command `postconf' exists in a user's PATH when running the SuSEconfig postfix module, *that command*, (whichever one is found first; not necessarily the intended one) will be run by SuSEconfig.
I think it goes without saying that you should never have a user writable directory in your path when you run things as root.
Really? So when you give sudo privileges to a user, including yourself, just how do you guarantee that the user will change his path before every use of sudo? You'd prefer to rely on that happening than to simply specify a full path to the correct command in the script? A system utility relying upon the command search path of its parent process is never a good idea.
I think the real bug is that SuSEconfig doesn't reset the path to something sane.
And the fact that it doesn't verify that a command it will execute repeatedly even exists before blindly attempting to execute it and write its output into Postfix's system-wide configuration file? And the fact that it returns 0, which indicates success, after multiple failures? Anyway, I got a response to my bug report (Ticket 20040414990000016) from SuSE:
This is a known bug that has been fixed in the upcoming SUSE Linux 9.1. For 9.0 this bug alone does not warrant an official update.
Apparently, they don't think it warrants warning anyone about it, either. Or even publishing the fact that it is known. -- Phil Mocek
On Thursday 15 April 2004 20.28, Phil Mocek wrote:
I think it goes without saying that you should never have a user writable directory in your path when you run things as root.
Really? So when you give sudo privileges to a user, including yourself, just how do you guarantee that the user will change his path before every use of sudo?
configure option --with-secure-path --with-secure-path[=PATH] Path used for every command run from sudo(8). If you don't trust the people running sudo to have a sane PATH environment variable you may want to use this. Another use is if you want to have the "root path" be separate from the "user path." You will need to customize the path for your site. NOTE: this is not applied to users in the group specified by --with-exemptgroup. If you do not specify a path, "/bin:/usr/ucb:/usr/bin:/usr/sbin:/sbin:/usr/etc:/etc" is used. I'm pretty sure there's a way to do it with pam as well
participants (2)
-
Anders Johansson -
Phil Mocek