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.swarbr...@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.
_______________________________________________
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
