opensmtpd: missing makemap binary

[romildo]

Describe the bug

The makemap utility is missing from the opensmtpd package.

$ ls -l /nix/store/2x67rywz1vkav70x4kn353ispbwl5lxs-opensmtpd-6.7.1p1/bin
total 808
-r-xr-xr-x 1 root root  67864 Dec 31  1969 smtp
-r-xr-xr-x 1 root root 194280 Dec 31  1969 smtpctl
-r-xr-xr-x 1 root root 560232 Dec 31  1969 smtpd

Notify maintainers

cc @obadz @Ekleog

Metadata

• system: "x86_64-linux"
• host os: Linux 5.8.11, NixOS, 21.03.git.a373d69351a (Okapi)
• multi-user?: yes
• sandbox: yes
• version: nix-env (Nix) 2.3.7
• channels(root): "nixos-21.03pre246062.420f89ceb26"
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute: opensmtpd
# a list of nixos modules affected by the problem
module:

[stale]

I marked this as stale due to inactivity. → More info

[JosephLucas]

It seems that makemap is expected to be supplied with sendmail (or equivalent opensmtpd).

Refs :

1. https://linux.die.net/man/8/makemap (man page linked to sendmail)
   The makemap command appeared in 4.4BSD.

2. https://man.openbsd.org/makemap.8 (this man page is linked to smptd)
   "makemap command first appeared in OpenBSD 4.6 as a replacement for the equivalent command shipped with sendmail."

3. https://www.cs.ait.ac.th/~on/O/oreilly/tcpip/sendmail/ch33_02.htm
   "The makemap program is supplied in source form with V8 sendmail. It may be supplied in pre-compiled form by your vendor"

It's hard to find makemap sources, but a binary ELF can be found at least in the deb package

http://archive.ubuntu.com/ubuntu/pool/universe/s/sendmail/sendmail-bin_8.15.2-20_amd64.deb

after unarchiving, we get it here

sendmail-bin_8.15.2-20_amd64/data.tar/usr/sbin/makemap

[Ekleog]

According to https://github.com/OpenSMTPD/OpenSMTPD/#setup-historical-interface it's an “historical interface,” which explains why it's not included by default.

That being said, it sounds like we could have it by just adding a symlink to the opensmtpd derivation's build. Does someone want to submit a PR adding it?

[JosephLucas]

I found the source I guess. it's very last version today should be ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.16.1.tar.gz
The reference page seems to be https://www.proofpoint.com/us/products/email-protection/open-source-email-solution
In a documentation here is what i read

The program "makemap" is used to build the databases used by version 8 sendmail, for things like the UserDB, mailertables, etc....

It is distributed as part of the basic operating system from some vendors, but source code for it is also included at the root level of the sendmail archive (at least, it is for sendmail 8.6.12 and 8.7.5, and presumably will continue to be as newer releases come out). However, it is not considered a "supported" part of version 8 sendmail. Just like the other source provided in the archive, the Makefile will likely need some tweaking for your specific site

[JosephLucas]

According to https://github.com/OpenSMTPD/OpenSMTPD/#setup-historical-interface it's an “historical interface,” which explains why it's not included by default.

That being said, it sounds like we could have it by just adding a symlink to the opensmtpd derivation's build. Does someone want to submit a PR adding it?

This should the best solution for opensmtpd to fix this issue. I guess that we could compile makemap from its source in opensmtpd and link the result in the final package of opensmtpd.

I may first do that for the sendmail package, since that is what I need. I am just wondering if it makes sense, since the doc states that makemap (in sendmail sources i guess)

is not considered a "supported" part of version 8 sendmail

[Ekleog]

This should the best solution for opensmtpd to fix this issue. I guess that we could compile makemap from its source in opensmtpd and link the result in the final package of opensmtpd.

I think there's a misunderstanding going on.

What I mean is that smtpctl already has all the source code needed to implement makemap's functionality according to OpenSMTPD's readme. The only thing required is a ln -s $out/bin/smtpctl $out/bin/makemap in the builder.

So there should be no need for any additional sources, only to add a symlink to smtpctl from the makemap name. You can check that by running something like sh -c 'exec -a makemap smtpctl'

[JosephLucas]

By adding ln -s $out/bin/smtpctl $out/bin/makemap in the builder, do you mean that smtpctl and makemap are two cmd names for the same thing ? i.e. with the same user interface.

What does exec -a cmd1 cmd2 ?

[Ekleog]

No, smtpctl inspects the name under which it was called to know whether it should behave as smtpctl or as makemap. exec -a is a way to lie to smtpctl, making it think it was called under the makemap name.

[JosephLucas]

I added

  postInstall = ''
    ln -s $out/bin/smtpctl $out/sbin/makemap
  '';

to the opensmtpd derivation.

When I install the derivation, executing makemap returns

makemap: unknown group smtpq

I will investigate what is the meaning of this group.

[JosephLucas]

I think that "smtpq" is a user and a group meant to be created by the opensmtpd module. It seems to me that this user/group (and not the default _smtpq) is coded into the source code of the makemap feature, due to the corresponding configuration flags of the derivation.

To get smtpq, one can enable the openstmpd module like this

services.opensmtpd = {
  enable = true;
  serverConfiguration = ''
    listen on lo
    action "noop" relay
    match for any action "noop"
  '';
};

(NB: It seems that opensmtpd needs at least one action for the configuration file to validate... Let's say this is a kind of noop configuration, for dev purpose. To avoid any conflict with real emails, we listen on lo (and not the wifi) while developing this.)

Once the module is enabled, installing the opensmtpd package and executing makemap returns now

makemap: this program must be setgid smtpq

Adding chown smtpq:smtpq $out/sbin/makemap in the postInstall hook and reinstalling/re-executing returns

chown: invalid user: 'smtpq:smtpq'

Same kind of errors with chown smtpq or chgr smtpq. That might be due to how the user and group are set into the nix store but I'm not sure.

[Ekleog]

You're right about the group being created by the opensmtpd module, and your changes to the derivation should now be correct! As for the setgid issue, the solution is not to chown inside the derivation build (which cannot happen anyway as all the files will be reset to be owned by root:root, and be setuid/setgid-less at the end of the build, for build sandboxing reasons). The solution would be to add another paragraph similar to the one here to the opensmtpd module, but replacing smtpctl with makemap:

https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/mail/opensmtpd.nix#L105-L109

[JosephLucas]

I did that and I tested with nixos-shell -I nipkgs=<local-nixpkgs>. Executing makemap does not complain about setgid smtpq anymore. But... an effective call, e.g. <some input> | makemap hash test.db keeps complaining with the same makemap: this program must be setgid smtpq message. This is strange since /run/wrappers/bin/makemap has its gid well set to smtpq -- idem for the corresponding smtpctl wrapper.

[Ekleog]

I don't have a lot of experience with nixos-shell, but I'd expect it to not work well with setuid/setgid wrappers. Have you tried with a regular eg. nixos-rebuild test -I nixpkgs=<local-nixpkgs>?

[JosephLucas]

Tried with nixos-rebuild build-vm --fast -I nixos-config=./vm.nix -I nixpkgs=. with same result. I will try soon to test a full system rebuild.

[JosephLucas]

Again, same result with nixos-rebuild test -I nixos-config=./configuration.nix -I nixpkgs=..

[JosephLucas]

Could someone reproduce this or did I make something wrong ?

[Ekleog]

Could you submit a PR with your nixpkgs and link it here, ideally copy-pasting your vm.nix? This way I'd be able to try reproducing, as this sounds weird to me :)

[stale]

I marked this as stale due to inactivity. → More info

[voidzero]

I'd like to give opensmtpd a try on one of my NixOS installs, and stumbled on this issue. Not sure if it's still relevant?

I've actually found this while trying to find an answer to the question whether we need to issue newaliases after creating an /etc/mail/aliases file. Maybe someone can shed some light on this too.