mail-mta/ssmtp package is installed with the /etc/ssmtp/ssmtp.conf as 0644 root:root. If the smtp server use to send mail requires login, the username and password will be stored in the ssmtp.conf file. Attempts to secure the ssmtp.conf file to make it 0600 root:root will cause ssmtp to fail for all users other then the owner of /etc/ssmtp/ssmtp.conf (in this case root). System software like sys-power/nut will fail to send email notification because the upsmon process that sends email notification is running as user nut. Reproducible: Always Steps to Reproduce: 1. Emerge and setup ssmtp 2. Change permission of /etc/ssmtp/ssmtp.conf to 0600 3. Send email with sendmail on a user account other then root Actual Results: Email send fail because ssmtp could not open /etc/ssmtp/ssmtp.conf Expected Results: Email send successfully. Software and versions where problem was noticed: mail-mta/ssmtp-2.61-r2 sys-power/nut-2.0.5-r2 Proposal: Add a new group e.g. ssmtp or sendmail and make /etc/ssmtp/ssmtp.conf ownership to be root:ssmtp and permission 0600. Admin can then chose to allow certain users permission to send email by adding those users to the ssmtp (or sendmail) group.
*** This bug has been marked as a duplicate of bug 132376 ***
Jakub, The bug 132376 which you have marked this one a dup of is about something very different. Bug 132376 is about the ssmtp with the -v flag showing the username and password. This one I’ve filed is to get ssmtp installed with different permission and maybe a new group for the config file. Please reconsider removing the dup status.
(In reply to comment #2) > This one I’ve filed is to get ssmtp installed with different permission and > maybe a new group for the config file. Well, if you read the other bug more carefully, you'll notice that it won't help at all, since the password will still leak.
(In reply to comment #3) > Well, if you read the other bug more carefully, you'll notice that it won't > help at all, since the password will still leak. I did read that other bug carefully and not only the description but all the comments as well. Please don't make those assumptions. The username and password leak via the -v mode would be a problem if I configure ssmtp to allow anyone to have access to ssmtp but that's not what I'm trying to do. I'm trying to configure the system to allow non-loginable users to have the ability to send mail, like the nut user. Actually if you think about it, if I add a user to the ssmtp group as I've proposed, it would mean that I knowingly and purposefully allowed the user to have permission to read the /etc/ssmtp/ssmtp.conf file. Exploiting the -v flag bug is actually a more difficult means to obtain the password in this case because the password output from ssmtp verbose mode is base64 encoded.
I've reopen the bug so that someone will answer to my comment above. Please understand that I am by no means trying to push this through no matter what. Also, I'm not trying to fix the world's problem with this bug report. Just a specific scenario that is different from the bug 132376. If my suggestion fix is not acceptable, please tell me so and also tell me why, instead of just marking this bug as dup to another bug that is not really related and tell me that it does not matter. All I ask is to treat me and my bug report as you would want me to treat gentoo developers.
(In reply to comment #5) > I've reopen the bug so that someone will answer to my comment above. > > Please understand that I am by no means trying to push this through no matter > what. Also, I'm not trying to fix the world's problem with this bug report. > Just a specific scenario that is different from the bug 132376. If my > suggestion fix is not acceptable, please tell me so and also tell me why, > instead of just marking this bug as dup to another bug that is not really > related and tell me that it does not matter. Though i'm not sure if that's the "common" case it's of course necessary and an important part of system-securtiy to protect sensible data from leaking by accident. This is fixed in ssmtp-2.62.
(In reply to comment #6) > Though i'm not sure if that's the "common" case it's of course necessary and an > important part of system-securtiy to protect sensible data from leaking by > accident. > > This is fixed in ssmtp-2.62. Thanks! Although this is a small bug and presumably an easy fix, I really do appreciate it.
Creating a ssmtp group is the wrong way to fix the data leakage problem. I really don't feel like going over 70 servers adding users to the ssmtp group ...
Agree with #8. ssmtp is supposed to be a replacement for /usr/sbin/sendmail, and that has traditionally always been available to all users on the system. I think this "security feature" (requiring membership of the ssmtp group) should be USE enabled, and not by default, so that users who aren't susceptible to the privacy leak (anyone who isn't making ssmtp authenticate) don't have to pay the penalty of stuffing around with group membership. The real solution would be to make ssmtp setuid root and have it drop privs after reading its config, or something, but that would add a lot of complexity to what is supposed to be a *dead-simple* MTA-replacement. I would suggest that the original reporter's problem can best be solved by using a real MTA, leaving the rest of us with a simple and working sendmail-replacement.
I agree with comment #9. I, and my users, find breaking a working setup like this inappropriate.
Can the ebuild perhaps be changed to propose a way to get back to the old behaviour, ie is there a simple way to make everyone part of the ssmtp group? In many cases ssmtp is only being used where security is largely a non issue
