Bug#809318: bts: overrides user-specified value of sendmail
Osamu Aoki
osamu at debian.org
Wed Mar 9 14:39:14 UTC 2016
control: severity -1 normal
Hi,
On Wed, Mar 09, 2016 at 02:22:04PM +0000, Daniel Shahaf wrote:
> Osamu Aoki wrote on Tue, Mar 08, 2016 at 23:08:58 +0900:
...
> There are two different issues being discussed in this thread. One of
> them is a wishlist item and one of them is not.
OK
> The root problem is that I ran «bts --sendmail=foo» and
> /usr/sbin/sendmail was executed. This can happen not only when the
> argument contains spaces (as in my original example) but also when the
> argument is an absolute path to an executable or a script that
> accidentally lacks the +x permission:
If it does not have +x permission, then script is not executed as
expected. So what is wrong? I do not understand.
> for example, «chmod -x
> ~/bin/mysendmail && bts --sendmail="$HOME/bin/mysendmail"» would
> reproduce the bug.
>
> As I said earlier, using the wrong sendmail binary can lead to an email
> being sent using incorrect settings (e.g., using the wrong relayhost or
> from address), which IMHO merits a greater-than-wishlist severity.
Yah but if that happend due to wrong file permission, who do you blame?
I am a bit intrigued. ...
> A separate issue is how the argument to the --sendmail option should be
> handled. There are several sensible options.¹ Currently, the code
> validates the argument, splits it on whitespace, and passes it to
> execve(). As you say, asking to add a mode whereby the argument would
> be passed to system() instead would be a wishlist item. However, I did
> not request that; I simply asked to change bts(1)'s behaviour when the
> validation fails.
Are you asking better error message? Aha, ... OK. But that is wishlist
though.
> I suggested that either the validation should not be
> done in the first place (just call execve() and let it error out), or
> a failed validation should result in a die() rather than in proceeding
> with a different sendmail binary than specified by the user.
OK. I see.
> Perhaps the "consider interpreting the argument to the --sendmail option
> using Text::ParseWords(3perl) or system(3)" discussion should be spun off
> into a separate bug report? After all, it is mostly orthogonal to the
> "Change the behaviour upon validation failure" issue.
Thanks,
Osamu
More information about the devscripts-devel
mailing list