On 30 Dec 2015, at 8:37, RW wrote:
On Tue, 29 Dec 2015 20:41:31 -0500
Bill Cole wrote:
On 29 Dec 2015, at 20:02, Ian Zimmerman wrote:
esired result.
Clearly you can do the su magic if needed.
Um, no.
Neither su nor sudo magically changes the permissions or ownership of
files.
No, but sudo allows sa-learn to run as the user that owns the database
and a group that can read the mailstore.
Yes, and that can be useful if you use virtual users instead of real
ones for the mailstore OR use inherited ACLs to give a special group
read access to it. If you use real users, you likely cannot and almost
certainly should not make the whole mailstore owned by one group with
read access.
And since it seems I muddled my point(s) again in the referenced message
I'll try restating one last time:
1. The sa-learn process for a system-wide BayesDB should not run as root
(because root should only handle suspect message data in the simplest of
ways, not attempting to parse it in any way.)
2. If you pass filenames as arguments to sa-learn, they must be files
that can be read by the user sa-learn runs as (in this case: "amavis".)
3. Maildir message files are normally only readable by either a real
user they are delivered to (if the mail system uses real OS users) or a
single low-privilege user whose only role is mailstore handling (if it
uses "virtual users" known only to mail and SASL facilities.) In either
case, it is often unsafe and/or inconvenient to use group ownership and
permissions to enable the system-wide BayesDB owner to read Maildir
message files directly. Inherited ACLs are a safer and more robust
approach, but not all filesystems support them.
Combining those:
A site with a system-wide BayesDB managed by the 'amavis' user and a
mailstore using Maildirs in which files are NOT generally readable by
that user can do one of the following to orchestrate re-training of
mis-classified messages or other post-delivery training with
human-judged messages:
A. Copy files from the Maildirs to a secured temporary directory, make
those copies readable by the amavis user, run sa-learn as amavis with
the directory as an argument, and clean up afterwards.
B. Pipe each message independently into a sa-learn process running as
amavis
C. Run a spamd as amavis and feed messages to it via spamc
Since these all involve running a learning process as amavis and passing
it data from files amavis can't read, most people will choose to drive
the overall process as root, being other users as needed. Arguably (C)
is potentially the safest because you can have the spamd started by the
amavis user listening only on a socket and have the spamc processes run
by whatever users own the various message files. It's also the most
complex (i.e. error-prone) and resource-heavy (process launch per
message +1) and many people won't understand that root shouldn't run the
spamc processes so maybe not the best thing to recommend, especially on
systems using real users for mail and/or with high launch costs. The
other two aren't concretely unsafe to do as root (as root wouldn't be
parsing message data) but would violate a dogmatic law against root
handling message data, if you have that in your catechism.
The more I think about it, the more I like the ACL approach more than
any of those 3: just give the BayesDB owner inherited read permissions
for all Maildirs and have it run sa-learn with the target files (or -f
filelist) as args. If the Maildirs aren't on an ACL-capable filesystem,
maybe that was a bad choice which merits correcting.
