Re: expiring mail from root's Maildirs?
(Sorry about previous mail)
On May 4, 2018, at 07:45, Aki Tuomi <aki.tuomi@dovecot.fi> wrote: Dovecot has hardcoded root prevention. For delivery, too.
So dovecot cannot expire, reindex, clean, repair, etc root mail?
The mail is crontab mail that is sent out to users via mutt. What would be the "right” way to do this? (The cron tasks run as root because they are scanning system logs on behalf of certain users and those scans cannot be run as the user.)
-- My main job is trying to come up with new and innovative and effective ways to reject even more mail. I'm up to about 97% now.
On Fri May 04 2018 10:59:22 GMT-0400 (Eastern Standard Time), LuKreme <kremels@kreme.com> wrote:
The mail is crontab mail that is sent out to users via mutt. What would be the "right” way to do this? (The cron tasks run as root because they are scanning system logs on behalf of certain users and those scans cannot be run as the user.)
Alias the local 'root' user to another account. This is best practice anyway...
On May 4, 2018, at 10:28, Tanstaafl <tanstaafl@libertytrek.org> wrote:
On Fri May 04 2018 10:59:22 GMT-0400 (Eastern Standard Time), LuKreme <kremels@kreme.com> wrote:
The mail is crontab mail that is sent out to users via mutt. What would be the "right” way to do this? (The cron tasks run as root because they are scanning system logs on behalf of certain users and those scans cannot be run as the user.)
Alias the local 'root' user to another account. This is best practice anyway...
For incoming mail the root user is aliased, but mail sent from cron via mutt is saved in root's home folder (was in /root/sent but I did get mutt to save it in /root/Maildir/.Sent/ instead.
I don't see anyway to change this, so I was hoping to expire the mail via doveadm.
-- My main job is trying to come up with new and innovative and effective ways to reject even more mail. I'm up to about 97% now.
LuKreme skrev den 2018-05-04 20:40:
Alias the local 'root' user to another account. This is best practice anyway...
+1
For incoming mail the root user is aliased, but mail sent from cron via mutt is saved in root's home folder (was in /root/sent but I did get mutt to save it in /root/Maildir/.Sent/ instead.
outgoing mail should not be stored into root uid 0
but that is still not sure mutt does allow that
try imap: auth, and do stay away from filesystem as root user
I don't see anyway to change this, so I was hoping to expire the mail via doveadm.
in gentoo its
# cat /etc/mail/aliases
root: some-other-unix-login
or
root: some-other-email-with-snable-a
after this file is edited, issue a "newaliases && postfix reload" :)
On May 4, 2018, at 16:07, Benny Pedersen <me@junc.eu> wrote:
outgoing mail should not be stored into root uid 0
And yet it is.
root: some-other-unix-login
Root has been aliased for decades. This has no impact on where and how mutt stores the mail it sends as root out of root’s crontab.
-- My main job is trying to come up with new and innovative and effective ways to reject even more mail. I'm up to about 97% now.
Can you use a set record= for root?
-- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: larryrtx@gmail.com US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
On 5/4/18, 8:50 PM, "dovecot on behalf of LuKreme" <dovecot-bounces@dovecot.org on behalf of kremels@kreme.com> wrote:
On May 4, 2018, at 16:07, Benny Pedersen <me@junc.eu> wrote:
>
> outgoing mail should not be stored into root uid 0
And yet it is.
> root: some-other-unix-login
Root has been aliased for decades. This has no impact on where and how mutt stores the mail it sends as root out of root’s crontab.
--
My main job is trying to come up with new and innovative and effective ways to reject even more mail. I'm up to about 97% now.And yet it is.
in muttrc you miss ~ or $(HOME)/something
root: some-other-unix-login
Root has been aliased for decades. This has no impact on where and how mutt stores the mail it sends as root out of root’s crontab.
root user can read mail files for all unix users, thats your fail, maybe crontab miss $(HOME) where it matters, but if it have and you start mutt as root it does not help, and you see the problem in allow root to do too much
i dont know mutt in detail, but its a fail to start mutt as root
mutt must be started as some-other-unix-login
the remaining fail is then in that users muttrc
On 2018-05-05 (06:52 MDT), Benny Pedersen <me@junc.eu> wrote:
And yet it is.
in muttrc you miss ~ or $(HOME)/something
No.
Root has been aliased for decades. This has no impact on where and how mutt stores the mail it sends as root out of root’s crontab.
root user can read mail files for all unix users, thats your fail, maybe crontab miss $(HOME) where it matters, but if it have and you start mutt as root it does not help, and you see the problem in allow root to do too much
There seems to be a basic misunderstanding here.
root has a crontab. Part of that crontab parses some system log files (that only root has access to) for user data and generates an email in HTML. That email is sent via mutt because the basic mail commands could not send an HTML email properly.
Mutt stores that email in ~root, and the email comes from the root user because that is who wins the crontab.
The $HOME fro the user is /root/
i dont know mutt in detail, but its a fail to start mutt as root
Since the mail is generated out of root's cron, however the mail is sent, that process is going to be started by root.
mutt must be started as some-other-unix-login
See above.
the remaining fail is then in that users muttrc
There is nothing wrong in the root muttrc.
-- U is for UNA who slipped down a drain V is for VICTOR squashed by a train
On 05 May 2018 at 20:14 "@lbutlr" <kremels@kreme.com> wrote:
On 2018-05-05 (06:52 MDT), Benny Pedersen <me@junc.eu> wrote:
And yet it is.
in muttrc you miss ~ or $(HOME)/something
No.
Root has been aliased for decades. This has no impact on where and how mutt stores the mail it sends as root out of root’s crontab.
root user can read mail files for all unix users, thats your fail, maybe crontab miss $(HOME) where it matters, but if it have and you start mutt as root it does not help, and you see the problem in allow root to do too much
There seems to be a basic misunderstanding here.
root has a crontab. Part of that crontab parses some system log files (that only root has access to) for user data and generates an email in HTML. That email is sent via mutt because the basic mail commands could not send an HTML email properly.
Mutt stores that email in ~root, and the email comes from the root user because that is who wins the crontab.
The $HOME fro the user is /root/
i dont know mutt in detail, but its a fail to start mutt as root
Since the mail is generated out of root's cron, however the mail is sent, that process is going to be started by root.
You could use tool like sudo or su to run mutt as non-root, instead of running it as root?
Aki
On 2018-05-05 (11:19 MDT), Aki Tuomi <aki.tuomi@dovecot.fi> wrote:
You could use tool like sudo or su to run mutt as non-root, instead of running it as root?
Maybe. Not sure if piping output in front to su will work, but I can certainly try it.
-- "Making music should not be left to the professionals." - Michelle Shocked
On 2018-05-05 (11:19 MDT), Aki Tuomi <aki.tuomi@dovecot.fi> wrote:
You could use tool like sudo or su to run mutt as non-root, instead of running it as root?
Thanks, that did work. Took a little, but no more sent mail in ~root.
-- Vi Veri Veniversum Vivus Vici
What happens if you put the following in /root/.muttrc: Set record='/file/to/put/mail/in' ?
-- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: larryrtx@gmail.com US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
On 5/5/18, 12:15 PM, "dovecot on behalf of @lbutlr" <dovecot-bounces@dovecot.org on behalf of kremels@kreme.com> wrote:
On 2018-05-05 (06:52 MDT), Benny Pedersen <me@junc.eu> wrote:
>
>> And yet it is.
>
> in muttrc you miss ~ or $(HOME)/something
No.
>> Root has been aliased for decades. This has no impact on where and how
>> mutt stores the mail it sends as root out of root’s crontab.
>
> root user can read mail files for all unix users, thats your fail, maybe crontab miss $(HOME) where it matters, but if it have and you start mutt as root it does not help, and you see the problem in allow root to do too much
There seems to be a basic misunderstanding here.
root has a crontab. Part of that crontab parses some system log files (that only root has access to) for user data and generates an email in HTML. That email is sent via mutt because the basic mail commands could not send an HTML email properly.
Mutt stores that email in ~root, and the email comes from the root user because that is who wins the crontab.
The $HOME fro the user is /root/
> i dont know mutt in detail, but its a fail to start mutt as root
Since the mail is generated out of root's cron, however the mail is sent, that process is going to be started by root.
> mutt must be started as some-other-unix-login
See above.
> the remaining fail is then in that users muttrc
There is nothing wrong in the root muttrc.
--
U is for UNA who slipped down a drain
V is for VICTOR squashed by a trainThe /file/to/put/mail/in?
Or ?
-- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: larryrtx@gmail.com US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
On 5/5/18, 3:21 PM, "dovecot on behalf of @lbutlr" <dovecot-bounces@dovecot.org on behalf of kremels@kreme.com> wrote:
On 2018-05-05 (11:19 MDT), Larry Rosenman <larryrtx@gmail.com> wrote:
>
> What happens if you put the following in /root/.muttrc:
> Set record='/file/to/put/mail/in'
I get a mail still owned by root.
--
May you live in interesting timesLarry Rosenman skrev den 2018-05-05 19:19:
What happens if you put the following in /root/.muttrc: Set record='/file/to/put/mail/in' ?
indeed possible, but this file will only be possible to read from root user
if it can be readed by other, its a security problem
participants (6)
-
＠lbutlr
-
Aki Tuomi
-
Benny Pedersen
-
Larry Rosenman
-
LuKreme
-
Tanstaafl