[pkg-go] Comments regarding prometheus-postfix-exporter_0.1.2-1_amd64.changes

[Daniel Swarbrick]

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.

The exporter is aware that the private interface of showq changed at 
least between Postfix 2.x and 3.x:

// The output format of this command depends on the version of Postfix
// used. Postfix 2.x uses a textual format, identical to the output of
// the 'mailq' command. Postfix 3.x uses a binary format, where entries
// are terminated using null bytes. Auto-detect the format by scanning
// for null bytes in the first 128 bytes of output.
func CollectShowqFromReader(file io.Reader, ch chan<- prometheus.Metric) 
error {
...

Upon guessing the ASCII or binary interface, it calls the relevant 
function to parse / decode the output.

There was also previously a "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.

In a perfect world, all daemons would already have Prometheus (or 
OpenMetrics) endpoints already baked in ;-)

[1]: 
https://github.com/kumina/postfix_exporter/commit/76f8dd448baf910ddcccab643ecc316fbedba5a8

On 04.02.19 15:23, Scott Kitterman wrote:
> 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:
>> 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 (https://prometheus.io/docs/operating/security/), 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:
>>> 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

-- 
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: daniel.swarbrick at cloud.ionos.com | Web: www.ionos.de

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-go-maintainers/attachments/20190204/954b5d81/attachment.html>