<div dir="ltr">Two thoughts come to mind:<div><br></div><div>* Hard-code into the application a list of common sendmail locations and search them</div><div>* Allow some kind of configuration (via file, env var, etc) to specify sendmail location at launch</div><div><br></div><div>The first may sound slightly dangerous, but if you're already searching the PATH for `sendmail`-named binaries, I don't think it's any worse. I'd definitely include a configuration override to set the location of the sendmail executable and override any searching (via list of paths or the PATH var).</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 9, 2016 at 7:46 PM, Jeremy Shaw <span dir="ltr"><<a href="mailto:jeremy@n-heptane.com" target="_blank">jeremy@n-heptane.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>I have a web application which needs to send mail using sendmail.</div><div><br></div><div>However, the way the system is configured, sendmail is not in the web server's $PATH.</div><div><br></div><div>There are two fixes for this -- change the init script so that sendmail is in the $PATH -- or modify the web server so that the admin can set the path to sendmail via the control panel.</div><div><br></div><div>At first the second option sounds good. But I wonder about the security implications. If someone manages to get the password for the admin control panel -- they could change the path to sendmail to something else -- like `vim` or `gcc` and then somehow craft a message that would place a backdoor on the system.<br><br>Now, given that the input to the message is going to be a mime message that sounds pretty difficult. But, then again, in December tons of Joomla sites were open to an exploit where a malformed user-agent header allowed hackers to execute arbitrary code.<br><br>Although in this case I care about sendmail, this is clearly an issue for any web application that depends on external binaries like pandoc, etc.<br><br>In my use case, I am dealing with a CMS and I assume the poor user doesn't know anything about Haskell, init scripts, ssh, etc. So, allowing the location to be changed via the admin panel makes things easier because it can be adapted to any distribution. (Clearly, I would start by checking the most common locations, but provide an escape hatch for oddballs).<br><br>But I don't like the idea of providing a potential attack vector.</div><div><br></div><div>Any thoughts ?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>- jeremy</div><div><br></div><div><br></div></font></span></div>
<br>_______________________________________________<br>
web-devel mailing list<br>
<a href="mailto:web-devel@haskell.org">web-devel@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/web-devel" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/web-devel</a><br>
<br></blockquote></div><br></div>