<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>The only public interface in this case would be parsing the
output of postqueue -p or unmarshalling the JSON output of
postqueue -j. Both would involve spawning an external binary,
which is somewhat frowned upon in the world of Prometheus
exporters.</p>
<p>The exporter is aware that the private interface of showq changed
at least between Postfix 2.x and 3.x:</p>
<p>// The output format of this command depends on the version of
Postfix<br>
// used. Postfix 2.x uses a textual format, identical to the
output of<br>
// the 'mailq' command. Postfix 3.x uses a binary format, where
entries<br>
// are terminated using null bytes. Auto-detect the format by
scanning<br>
// for null bytes in the first 128 bytes of output.<br>
func CollectShowqFromReader(file io.Reader, ch chan<-
prometheus.Metric) error {<br>
...</p>
<p>Upon guessing the ASCII or binary interface, it calls the
relevant function to parse / decode the output.<br>
</p>
<p>There was also previously a "<span class="pl-c">CollectShowqFromFile"
function, which appears that it could have read the postqueue
output from a regularly-generated file, similar to the
node_exporter textfile collector approach. This function is
still in the source, but was commented out [1] when a linter
identified it as dead code.<br>
</span></p>
<p><span class="pl-c">In a perfect world, all daemons would already
have Prometheus (or OpenMetrics) endpoints already baked in ;-)<br>
</span></p>
<p><span class="pl-c">[1]:
<a class="moz-txt-link-freetext" href="https://github.com/kumina/postfix_exporter/commit/76f8dd448baf910ddcccab643ecc316fbedba5a8">https://github.com/kumina/postfix_exporter/commit/76f8dd448baf910ddcccab643ecc316fbedba5a8</a><br>
</span></p>
<div class="moz-cite-prefix">On 04.02.19 15:23, Scott Kitterman
wrote:<br>
</div>
<blockquote type="cite" cite="mid:4134297.4J0xxVTcyH@kitterma-e6430">
<pre class="moz-quote-pre" wrap="">The distinction is that showq is specifically documented as an internal
interface and postqueue is public. From an FTP team perspective, this isn't
more problematic than other things in the archive, so I'm going to accept is,
but I would encourage you to work with upstream to move to the public
interface (even if that means working with the postfix developers to extend
postqueue).
Scott K
On Monday, February 04, 2019 11:10:34 AM Daniel Swarbrick wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hi Scott,
Thanks for your feedback.
On Debian (and other) systems running Postfix, /usr/bin/mailq is a
symlink to /usr/sbin/sendmail. When running "sendmail -bp" to view the
contents of the queue, this execve's "/usr/sbin/postqueue -p", which
outputs the contents of the mailq in the traditional format. Postqueue
is a setgid binary (postdrop group), which is how it is able to access
the showq socket inside Postfix's chroot (/var/spool/postfix).
There is nothing to prevent local shell users from running this command
as often as they please, however Postfix limits the number of
simultaneous showq processes to 100 by default.
Obviously prometheus-postfix-exporter removes the hurdle that an
attacker needs to have a local shell account. In the Prometheus docs on
security (<a class="moz-txt-link-freetext" href="https://prometheus.io/docs/operating/security/">https://prometheus.io/docs/operating/security/</a>), they state:
Prometheus and its components do not provide any server-side
authentication, authorisation or encryption. If you require this, it
is recommended to use a reverse proxy.
It is generally accepted in the Prometheus community that exporters
should only be accessible to trusted clients. Since HTTP request
security is (currently) out of scope for Prometheus, the usual practice
is to host exporters behind a small reverse proxy daemon, which
implements authn / authz and optionally request rate limiting, if
security is a concern.
Many of the already published Prometheus exporters have the potential to
DoS the services that they connect to or hosts they run on, if they are
scraped frequently enough.
On 02.02.19 08:28, Scott Kitterman wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">I am concerned that an external package using showq is going to be
problematic. Some excerpts from showq (8):
The showq(8) daemon reports the Postfix mail queue status. The output is
meant to be formatted by the postqueue(1) command, as it emulates the
Sendmail `mailq' command.
SECURITY
The showq(8) daemon can run in a chroot jail at fixed low
privilege, and takes no input from the client. Its service port is
accessible to local untrusted users, so the service can be susceptible to
denial of service attacks.
STANDARDS
None. The showq(8) daemon does not interact with the outside
world.
We don't install showq on the system path for a reason.
How does this package make sure it doesn't DOS postfix?
Before we accept/reject this package, I'd appreciate some feedback on the
design. It's not obviously something that is appropriate for Debian.
Scott K
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Daniel Swarbrick
Senior Systems Developer
1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
Phone: +49 30 57700-8299 | Fax: +49 30 57700-8598
E-mail: <a class="moz-txt-link-abbreviated" href="mailto:daniel.swarbrick@cloud.ionos.com">daniel.swarbrick@cloud.ionos.com</a> | Web: <a class="moz-txt-link-abbreviated" href="http://www.ionos.de">www.ionos.de</a>
Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss
Member of United Internet
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient of this e-mail, you are hereby notified that saving,
distribution or use of the content of this e-mail in any way is prohibited. If
you have received this e-mail in error, please notify the sender and delete the
e-mail.</pre>
</body>
</html>