Add a new 'passwordfd' command and '--passwordfd' option

[steelman]

This allows receiving the password from a parent process.

The code for reading from the file descriptor is a repuprposed password_eval() function removed in commit e16c5d9 ("remove password_eval() which moved to eval()").

[marlam]

Hi, thank you for your patch and sorry that it took me so long to have a look at it.

Can you please explain the use case for this change? Why does --password-eval not work?

[steelman]

@marlam

Why does --password-eval not work?

In my case in Debian, the AppArmor policy for msmtp limits what msmtp can run. The way to overcome this limitation is to make a wrapper that obtains the password (in whatever way), does some fd juggling to pass its standard descriptors to msmtp and a pipe with a buffered password.

I believe there are other situations where it may be preferable to obtain the password from the parent process without starting any extra commands.

@balejk Thanks for spotting this and making me look through the patch once again to find a debug fprintf().

[marlam]

In my case in Debian, the AppArmor policy for msmtp limits what msmtp can run. The way to overcome this limitation is to make a wrapper that obtains the password (in whatever way), does some fd juggling to pass its standard descriptors to msmtp and a pipe with a buffered password.

I am not inclined to include patches that work around problems with distribution-specific AppArmor profiles. AppArmor in the past has broken multiple msmtp features (see Debian bug 975333), and all the user gets is 'Permission denied' without a hint of what caused the error. I am therefore not convinced that having AppArmor enabled for msmtp makes sense in the first place, and if a distribution insists on having an AppArmor profile, it should neither silently break msmtp functionality nor require elaborate workarounds.

[steelman]

Well, to clear some things out. AppArmor itself is not a problem at all. The configuration provided by the distribution which limits what programs msmtp may start is. But I consider this configuration quite reasonable that it prevents a network facing program like msmtp from spawning awk or perl which I wanted to use to parse my password database.

After I created the patch it occurred to me that I can't make use of it because Emacs (which I use to write mail) can't start child process with more than one pipe between them connected to the child's stdin.

However, I still find this patch (which I conceptually copied from GnuPG) valuable regardless of the whole AppArmor situation which was just an excuse to sit and write some code. I believe anonymous pipes are the best (maybe second best after Linux kernel keyring, but that's a different story) way to pass passwords between processes.

I hope I managed to explain why I created the patch and why I think it may be useful for other users. The decision is yours.

Kind regards.

[marlam]

Yes, I can see that one can construct a use case for this even when ignoring problematic AppArmor profiles, but this looks like one of those features that in the end will be used by at most a handful of users. GPG even lists its corresponding option in the Esoteric Options section. Also, there are alternatives, e.g. using a keyring to store the password. So, the balance between usefulness and complexity/featuritis does not look too good from my point of view.

[steelman]

Anyway, thanks for making msmtp. It's an awesome piece of software (-:

[marlam]

OK, I'll close this now.