Score:0

procmail - file permissions?

br flag

Ubuntu 18.04, running postfix and procmail I have a .procmailrc and a .forward and all that. I configured procmail to log to a specific file, and the only way I can get it to work is by setting that file to be world readable and writable. Obviously this is no good. How do I determine what user account procmail is using to access files so I can lock it down to that account? (root:root and 644 didnt work....)

I have the same problem with a file written by a python script which procmail recipe calls - the only way to get it to work so far is to make the file 777. Again, I dont know how to figure out what account is trying to access this file when the python script runs.

ETA: The .procmailrc is as follows:

# Set to yes when debugging
VERBOSE=yes

# Default INBOX
INBOX=$MAIL

# Directory for storing procmail-related files
PMDIR=$HOME/procmail

# Uncomment the following line to get logging
LOGFILE=/var/log/procmail/pmlog

:0wc:
| /usr/bin/python /home/[MyUsername]/scripts/mailproc.py

mailproc.py is a simple python script which postprocesses the email message for a specific purpose. I added a call to "whoami" in the py file and discovered that the py is running under the user who owns the procmailrc file.

But I still cant figure out who should own the procmail log file. Having it root:root and 644 wont work.

tripleee avatar
nz flag
Procmail running out of your `.forward` should simply run with your own permissions (though also, the `.forward` should not be necessary if Postfix is configured to use Procmail as your LDA, as I believe it will be out of the box). Could you please [edit] to clarify where and how exactly you are trying to run Procmail, and how you are trying to write to this file?
tripleee avatar
nz flag
In general. Procmail run by `root` starts as `root` and reads `/etc/procmailrc` until it reaches a `DROPPRIVS=yes` statement or the end of the file, then switches to the delivering user's account and reads (the rest of `/etc/procmailrc` if there was a `DROPPRIVS`, and then) their `.procmailrc` if it exists, then if it doesn't exist, or Procmail falls off the end of it without delivering the message, delivers to `$DEFAULT`. You can further restrict the pemissions it uses when creating a file by setting `UMASK`, like the `umask` shell command. This is all documented in the man page.
tripleee avatar
nz flag
As an aside, the `c` flag on your Python recipe looks wrong. Or do you really want to deliver to your `$DEFAULT` mailbox _as well_ as to your Python script? The second colon is also wrong; you either have to give up locking, or specify an explicit lock file. See further https://www.iki.fi/era/procmail/mini-faq.html#locking
alabamatoy avatar
br flag
Thanks for the recipe comments - you are fixing problems I didnt even realize I had.
Score:0
nz flag

There is no sane way for a normal user to write to the system's log files.

What you might be able to do as a partial workaround is to not set a LOGFILE at all. Procmail will still write log entries to standard error, and so perhaps that output will be sent to the Postfix log file (or perhaps you can add an explicit redirection to the specified location where you run procmail).

A much simpler and obvious solution is to have the user's .procmailrc write the log file to their home directory, where obviously they routinely have write access.

tripleee avatar
nz flag
Actually there are tools like `logger` which allow you to emit a message to the system logging facility, but you can't directly control whether it gets written to a file, or which file in that case.
tripleee avatar
nz flag
Do you feel something is still missing from this answer? Otherwise, if this solved your problem, please consider accepting it. If you prefer, you are welcome to post an answer of your own, and accepting that. Accepting an answer helps future visitors by marking your problem as resolved. See also [help.](/help/someone-answers)
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.