On 7/10/19 10:45 PM, Tim via users wrote:
Samuel Sieb:
What is the output of the following command:
ls -lZ /home/tim/.fetchmailrc
If it doesn't include "fetchmail_home_t", then do:
restorecon -v /home/tim/.fetchmailrc
Then try again.
$ ls -lZ /home/tim/.fetchmailrc
-rw-------. tim tim unconfined_u:object_r:user_home_t:s0 /home/tim/.fetchmailrc
^^^^^^^^^^^^^^^^
$restorecon -v /home/tim/.fetchmailrc
restorecon reset /home/tim/.fetchmailrc context unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:fetchmail_home_t:s0
$ ls -lZ /home/tim/.fetchmailrc
-rw-------. tim tim unconfined_u:object_r:fetchmail_home_t:s0 /home/tim/.fetchmailrc
^^^^^^^^^^^^^^^^^^^^^
If I erase the .fetchmailrc file, then do a
touch /home/tim/.fetchmailrc
to create a brand new file, it gets the same contexts as I started out
with (r:user_home_t:s0 without any fetchmail in them).
I was of the understanding that creating a new file should get the
appropriate contexts, the same ones that using restorecon would set.
I see the same thing. And I had the same expectation.
And on that server, SELinux was enabled but permissive, and I'd always
just run the fetchmail daemons from /etc/rc.local file.
And so it would work.
One thing I don't understand is why, if the SELinux contexts were
wrong, how some things could make fetchmail work, but rc.local could
not.
It's because of the context. When run from cron, it is probably
unconfined, but when run from systemd, it starts as init and transitions
to fetchmail_t which has tight restrictions.
# sealert -l f6595cf9-418b-4630-8e08-a5b0c22512ef
SELinux is preventing /usr/bin/fetchmail from read access on the file .fetchmailrc.
Target Context unconfined_u:object_r:user_home_t:s0
At some point you reset the context on the file. It's not correct again.
It's probably safe for me to add that exception as it instructs, so
I've done so:
# ausearch -c 'fetchmail' --raw | audit2allow -M my-fetchmail
******************** IMPORTANT ***********************
To make this policy package active, execute:
semodule -i my-fetchmail.pp
# semodule -i my-fetchmail.pp
If you set the correct context on the file, you shouldn't need that one.
Reboot, still not working, still getting similar error messages in the
log, except it's about the pid file.
There are no rules to allow it to access or write the .pid file.
Fortunately, the new server is quick to boot. Doing lots of reboot
tests is a pain. But I'm bashing my head into a brick wall over
something that ought to be a lot simpler.
You don't have to reboot. You can run "systemctl start rc-local"
manually. If that doesn't fail, then you will have to also run
"systemctl stop rc-local" after.
What is it about rc.local that is having so many permission problems,
when crontab can run the thing? Putting asside this current malarkey,
it *WAS* a lot easier to set up some command lines in rc.local to run
fetchmail daemons.
As I mentioned earlier, it has to do the execution context.
---------- tangential sidetrack ---------->
Another big issue I'm waiting to encounter on the new server, is the
parallel running of services. The old server was pre-systemd, and
things ran in a set sequence. Network needed to come up first, then
DNS, then DHCPD, then dovecot, then it probably didn't matter which
other servers started in which sequence.
I haven't yet got my head around making systemd services wait, though
I'd occasionally come across semi-recent Fedora installations where the
pre-configured wait for network was only waiting for network to begin
start, not waiting for network to actually be ready for use. The
mailing lists brought that up quite a lot.
You have to specify what other service needs to be running before this
service. In the case of the network, you probably want to add the
following two lines to the service:
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
