| 1 |
On Monday 20 Jul 2015 15:23:30 Walter Dnes wrote: |
| 2 |
> On Mon, Jul 20, 2015 at 01:21:56PM +0200, Marc Joliet wrote |
| 3 |
> |
| 4 |
> > This choice came about because I switched from fcron to systemd-cron, |
| 5 |
> > which runs its mail_on_failure script as user "nobody", which caused |
| 6 |
> > my current "passwordeval" command ("cat somefile", somefile having |
| 7 |
> > a mode mask of 0600) |
| 8 |
> |
| 9 |
> That is the wrong, wrong, wrong way to do it. |
| 10 |
> |
| 11 |
> > to fail due to insufficient access rights. I really didn't want to |
| 12 |
> > deal with how to properly solve that, and I don't think it's possible |
| 13 |
> > (at least not with msmtp). I mean, the problem statement is |
| 14 |
> > basically "How do I securely give every user access to the password?". |
| 15 |
> > Once stated that way, I think the difficulty with the problem becomes |
| 16 |
> > fairly obvious. |
| 17 |
> |
| 18 |
> The correct question is "how do I allow user 'nobody' to execute a |
| 19 |
> one-off command as another user. The solution is sudoers. Emerge sudo |
| 20 |
> and set up a file in /etc/sudoers.d. I use /etc/sudoers.d/001 because |
| 21 |
> I'm not creative with filenames. Here is an example entry... |
| 22 |
> |
| 23 |
> waltdnes d531 = (root) NOPASSWD: /usr/sbin/hibernate |
| 24 |
> |
| 25 |
> The explanation... |
| 26 |
> |
| 27 |
> waltdnes (the user being allowed to run the command) |
| 28 |
> d531 (the machine name in /etc/hosts) |
| 29 |
> (root) (the user privilege to run as) |
| 30 |
> NOPASSWD: (password is not required; no ugly "cat somefile" hack) |
| 31 |
> /usr/sbin/hibernate (the command to run) |
| 32 |
> |
| 33 |
> As regular user "waltdnes", I execute the command... |
| 34 |
> |
| 35 |
> sudo /usr/sbin/hibernate |
| 36 |
> |
| 37 |
> ...and I get the system to hibernate, which normally requires root level |
| 38 |
> privileges. I'm lazy, so I set up a script ~/bin/hb that runs the above |
| 39 |
> command. I only have to execute "hb" to hibernate. This approach is |
| 40 |
> very granular, because it can be set up to allow one user to execute one |
| 41 |
> specifc command. If you wish, you can use wildcards, and the special |
| 42 |
> "ALL" word to open up privileges more widely. |
| 43 |
|
| 44 |
This is all good and dandy, but letting user "nobody" read your mail accoutn |
| 45 |
passwd may not be the safest approach to sending email messages from your |
| 46 |
machine. |
| 47 |
-- |
| 48 |
Regards, |
| 49 |
Mick |
Archives