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