Jonathan Hammer:
> Hi,
>
> We are running Postfix on macOS and making use of `maillog_file =
> /dev/stdout` and `postfix start-fg` to send our logs to stdout.
> Not using Docker.
"postfix start-fg" ands "maillog_file = /dev/stdout" are for use
with containers. I am surprised that it works at all elsewhere. For
example, stdout logging cannot work correctly when a non-root user
invokes a Postfix program (the program can't talk to postlogd, and
will try to write to its own stdout). I have done no analysis of
what else might not work when a contasiner configuration is used
for stand-alone operation.
> We would like to pipe the logs from stdout to another process to
> do some analysis and post-processing, like so:
>
> $ postfix start-fg | our-custom-log-analyzer?
Run it in a container. What you are doing is a nightmare. If the
custom analyzer fails then Postfix will continue to run but logging
will be lost (postlogd has no way for it to tell you so). At least
in the docker case I might hope that SIGPIPE will have some effect.
> However, in this configuration, Postfix fails to start and logs this error:
>
> fatal: open logfile ?/dev/stdout?: file has 0 hard links
>
> If we don?t pipe the output, it starts just fine.
See above.
> It looks like this check in `safe_open_exist` is to blame:
>
> } else if (fstat_st->st_nlink != 1) {
> vstring_sprintf(why, "file has %d hard links",
> (int) fstat_st->st_nlink);
> errno = EPERM;
>
> When we pipe the output, st_nlink is 0, causing this check to fail.
> Do you think it would be acceptable to relax this check to `if
> (fstat_st->st_nlink > 1)`, as shown in the attached patch?
This function is security critical, so I can't quickly say if this
would introduce a security hole. On Linux and *BSD, /dev/stdout is
a symlink to a file that has exactly one hard link, so this hack
should not be implemented for those systems,
Wietse
