I accidentally hit send on the last email instead of pasting...
On 7/11/19 12:41 AM, Samuel Sieb wrote:
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:
After=network-online.target
Wants=network-online.target