From: Marc Joliet <marcec@gmx.de>
To: gentoo-user@lists.gentoo.org
Subject: Re: [SOLVED] Re: [gentoo-user] msmtp vs. nullmailer
Date: Thu, 23 Jul 2015 22:51:53 +0200 [thread overview]
Message-ID: <20150723225153.4b1b7657@thetick> (raw)
In-Reply-To: <20150720142330.GA21609@waltdnes.org>
[-- Attachment #1: Type: text/plain, Size: 4229 bytes --]
Am Mon, 20 Jul 2015 10:23:30 -0400
schrieb "Walter Dnes" <waltdnes@waltdnes.org>:
> On Mon, Jul 20, 2015 at 01:21:56PM +0200, Marc Joliet wrote
>
> > This choice came about because I switched from fcron to systemd-cron,
> > which runs its mail_on_failure script as user "nobody", which caused
> > my current "passwordeval" command ("cat somefile", somefile having
> > a mode mask of 0600)
>
> That is the wrong, wrong, wrong way to do it.
I know, it somewhat defeats the purpose. In my defense, it was supposed to be
temporary so that I could get msmtp working quickly until I was sure that I
wanted to keep it.
> > to fail due to insufficient access rights. I really didn't want to
> > deal with how to properly solve that, and I don't think it's possible
> > (at least not with msmtp). I mean, the problem statement is
> > basically "How do I securely give every user access to the password?".
> > Once stated that way, I think the difficulty with the problem becomes
> > fairly obvious.
>
> The correct question is "how do I allow user 'nobody' to execute a
> one-off command as another user.
My thought was admittedly somewhat academic: I didn't want to assume that only
root and nobody wanted to send emails. However, I notice that the only
software I have installed that needs to be able to send email is (insofar that
there aren't any packages missing a dependency on virtual/mta or virtual/mailx):
- portage (though only if you configure it appropriately)
- smartd (via the "mail" program instead of sendmail)
- *cron
- sudo (though I don't know under what circumstances and as what user, though I
expect it to send emails as root)
All run as root except for *cron, which in the case of systemd-cron sends mails
as "nobody" (I don't remember how fcron or any of the other implementations do
it).
So from a practical point of view, you are right that the problem was limited
to dealing with user "nobody". Though who knows what will happen after an
upgrade or package migration? Despite being a Gentoo user, I'm not interested
in micromanaging *every* aspect of my system (only the fun parts).
> The solution is sudoers. Emerge sudo
> and set up a file in /etc/sudoers.d. I use /etc/sudoers.d/001 because
> I'm not creative with filenames. Here is an example entry...
>
> waltdnes d531 = (root) NOPASSWD: /usr/sbin/hibernate
>
> The explanation...
>
> waltdnes (the user being allowed to run the command)
> d531 (the machine name in /etc/hosts)
> (root) (the user privilege to run as)
> NOPASSWD: (password is not required; no ugly "cat somefile" hack)
> /usr/sbin/hibernate (the command to run)
>
> As regular user "waltdnes", I execute the command...
>
> sudo /usr/sbin/hibernate
>
> ...and I get the system to hibernate, which normally requires root level
> privileges. I'm lazy, so I set up a script ~/bin/hb that runs the above
> command. I only have to execute "hb" to hibernate. This approach is
> very granular, because it can be set up to allow one user to execute one
> specifc command. If you wish, you can use wildcards, and the special
> "ALL" word to open up privileges more widely.
I actually know about this and have a wildcard rule for cpupower. I agree with
Mick's point, though, which partially ties into *my* point: I want to limit
access to the password (file) to as few users as possible, and "nobody" is used
as a catch-all, so I wouldn't fully know *what* exactly I'm giving access to my
email account password.
I just didn't see any sane way to handle this with msmtp, which to me seems
more and more like it's primarily designed for use by regular users as
opposed to system services (various hints point to this, such as that the
system-wide example [0] only defines a default account without a password, or
the Gentoo package description I mentioned before).
Anyway, I'm happy with nullmailer right now.
[0] http://msmtp.sourceforge.net/doc/msmtp.html#A-system-wide-configuration-file
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup
[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
prev parent reply other threads:[~2015-07-23 20:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-08 9:47 [gentoo-user] msmtp vs. nullmailer Marc Joliet
2015-06-08 12:24 ` Guy-Laurent Subri
2015-06-08 13:27 ` [gentoo-user] " Grant Edwards
2015-06-12 7:24 ` Marc Joliet
2015-06-12 7:34 ` Marc Joliet
2015-06-08 22:45 ` [gentoo-user] " Walter Dnes
2015-06-09 5:27 ` Mick
2015-07-20 11:21 ` [SOLVED] " Marc Joliet
2015-07-20 14:23 ` Walter Dnes
2015-07-20 17:49 ` Mick
2015-07-20 21:50 ` Walter Dnes
2015-07-20 22:24 ` Mick
2015-07-20 22:32 ` Alan McKinnon
2015-07-20 22:29 ` Alan McKinnon
2015-07-23 20:51 ` Marc Joliet [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150723225153.4b1b7657@thetick \
--to=marcec@gmx.de \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox