Bugzilla Bug 187841

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