account default not found: no configuration file available

[Peter Selinger]

If ~/.msmtprc is a symbolic link, the user gets the below error message, regardless of the permissions of the link's target.

This was originally reported as Debian bug 919326 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919326) and was closed because it was supposedly fixed in version 1.8.2. However, the bug is still present in 1.8.3.

>>>>>>

$ msmtp -d <email address hidden>

ignoring system configuration file /etc/msmtprc: No such file or directory
ignoring user configuration file /home/selinger/.msmtprc: Permission denied
falling back to default account
msmtp: account default not found: no configuration file available

$ ll .msmtprc
lrwxrwxrwx 1 selinger selinger 24 Aug 13 08:06 .msmtprc -> .myconfig/msmtprc-yoneda
$ ll -L .msmtprc
-rw------- 1 selinger selinger 2900 Jul 23 18:31 .msmtprc

>>>>>>

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: msmtp 1.8.3-1
ProcVersionSignature: Ubuntu 5.0.0-23.24-generic 5.0.15
Uname: Linux 5.0.0-23-generic x86_64
ApportVersion: 2.20.10-0ubuntu27.1
Architecture: amd64
Date: Tue Aug 13 09:39:34 2019
InstallationDate: Installed on 2013-03-26 (2330 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
SourcePackage: msmtp
UpgradeStatus: Upgraded to disco on 2019-08-12 (0 days ago)

[Simon Déziel (sdeziel)]

Hi Peter,

The failure to read your msmtp's config is probably because it's a symlink that points to a non-standard location that is not authorized by default in the Apparmor profile. The Apparmor profile allows the following locations:

  /etc/msmtprc r,
  owner @{HOME}/.msmtp* r,
  owner @{HOME}/**/.msmtprc r,
  owner @{HOME}/**/dot_msmtprc r,
  owner @{HOME}/.config/msmtp/* r,

So you could do various thing to make it work on your setup:

1) move the config to a standard location (see above) and update the symlink
2) add this local override rule to /etc/apparmor.d/local/usr.bin.msmtp:
  owner @{HOME}/.myconfig/msmtprc-* r,
3) disable the Apparmor profile

For 2 and 3, please refer to the README.Debian file for detailed instructions.

For now, I'll mark the bug as invalid due to the non-standard location used. If you have any questions or the above proposed solutions don't work, please let me know. Thank you!

[Peter Selinger (selinger)]

Hi Simon,

thanks for the explanation. I guess this is a limitation of Apparmor
then, rather than a bug of msmtp. I will work around it using one of
the methods you suggested.

On the bigger question, I don't konw why it makes sense to armor
msmtp. Is it an especially untrusted application? For example, the -C
option seems kind of pointless if the app can't actually read a file
that the user explicitly specifies on the command line.

Would it be possible to provide a more useful error message?
"Permission denied" is very generic and did not point me to the actual
cause of the error. Perhaps, because the failure is caused by a system
call, it is not possible to get more specific information about why
the permission was denied. But if it is possible to mention Apparmor
in the error message, that might be a good idea.

Thanks, -- Peter

Simon_Déziel wrote:

>
> Hi Peter,
>
> The failure to read your msmtp's config is probably because it's a
> symlink that points to a non-standard location that is not authorized by
> default in the Apparmor profile. The Apparmor profile allows the
> following locations:
>
> /etc/msmtprc r,
> owner @{HOME}/.msmtp* r,
> owner @{HOME}/**/.msmtprc r,
> owner @{HOME}/**/dot_msmtprc r,
> owner @{HOME}/.config/msmtp/* r,
>
> So you could do various thing to make it work on your setup:
>
> 1) move the config to a standard location (see above) and update the symlink
> 2) add this local override rule to /etc/apparmor.d/local/usr.bin.msmtp:
> owner @{HOME}/.myconfig/msmtprc-* r,
> 3) disable the Apparmor profile
>
> For 2 and 3, please refer to the README.Debian file for detailed
> instructions.
>
> For now, I'll mark the bug as invalid due to the non-standard location
> used. If you have any questions or the above proposed solutions don't
> work, please let me know. Thank you!
>
> ** Changed in: msmtp (Ubuntu)
> Status: New => Invalid
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1840035
>
> Title:
> account default not found: no configuration file available
>
> Status in msmtp package in Ubuntu:
> Invalid
>
> Bug description:
> If ~/.msmtprc is a symbolic link, the user gets the below error
> message, regardless of the permissions of the link's target.
>
> This was originally reported as Debian bug 919326
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919326) and was
> closed because it was supposedly fixed in version 1.8.2. However, the
> bug is still present in 1.8.3.
>
> >>>>>>
>
> $ msmtp -d <email address hidden>
>
> ignoring system configuration file /etc/msmtprc: No such file or directory
> ignoring user configuration file /home/selinger/.msmtprc: Permission denied
> falling back to default account
> msmtp: account default not found: no configuration file available
>
> $ ll .msmtprc
> lrwxrwxrwx 1 selinger selinger 24 Aug 13 08:06 .msmtprc -> .myconfig/msmtprc-yoneda
> $ ll -L .msmtprc
> -rw------- 1 selinger selinger 2900 Jul 23 18:31 .msmtprc
...

[Simon Déziel (sdeziel)]

Hi Peter,

If you don't see the value of applying an Apparmor profile to msmtp please disable it. The package should remember this decision on upgrades and not re-enable it behind your back.

I do agree that it kinds of defeat the -C option but the Apparmor profile was designed to accommodate the most common use cases with the option to handle less common ones via the local override mechanism.

Regarding the generic "Permission denied" I guess that's a problem with all LSMs. More details about the denial are logged to dmesg but I'm afraid that's all we got in terms of reporting.

Regards,
Simon