Marc Schwartz wrote:
On Mon, 2006-06-26 at 22:56 +0100, Paul Howarth wrote:
On Mon, 2006-06-26 at 12:47 -0500, Marc Schwartz (via MN) wrote:
<snip>
Can you check that the dccproc being invoked by spamassassin is the one
in /usr/local/bin and that its context type is dcc_client_exec_t?
dccproc only exists in two locations:
/var/dcc/build/dcc/dccproc/dccproc
and
/usr/local/bin/dccproc
The former is where dcc does it's build each night.
It was:
user_u:object_r:bin_t
I ran restorecon on it and now:
system_u:object_r:dcc_client_exec_t
However, thinking that the build process might change the context, I
manually ran updatedcc via sudo from the CLI. Sure enough, the context
is back to:
user_u:object_r:bin_t
So the change in context will occur every night. :-(
Should I add a restorecon to crontab after updatedcc runs?
Yes.
Done. This takes place 10 minutes after updatedcc runs, in case there is
some delay in the download. I moved the pyzor update to 1:15 am and the
razor update stays at 1:20 am.
Also, there is some configuration info here:
http://www.rhyolite.com/anti-spam/dcc/dcc-tree/INSTALL.html
where some settings (ie. UID) might be apropos here. If something makes
sense to change, let me know.
It looks tricky. There's one script that both compiles and then installs
the updated version. It only needs to be root to do the install, and
would need changing to split the functionality.
Agreed. Without fundamentally changing the script, this would be
problematic.
I think a better updating option would be to get dcc into a third-party
repository and use the usual yum method to update the software.
Whilst it's not free software and hence unsuitable for Extras, I don't
think the license would prevent it being packaged somewhere else.
Paul.
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
