Tim wrote:
>> But that won't work, anymore. The log returns:
>>
>> rc.local: fetchmail: open: /home/tim/.fetchmailrc: Permission denied
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
^^^^^^^^^^^^^^^^^^^^^
**************************************************
I've marked the noticeable changes with carats.
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.
In setting things up, I'd simply copied the fetchmailrc file from the
previous server (using command line "cp" across a NFS export of my old
/home directory tree). It's contexts on the old server are this:
$ ls -lZ /home/tim/.fetchmailrc
-rw------- tim tim user_u:object_r:user_home_t /home/tim/.fetchmailrc
And on that server, SELinux was enabled but permissive, and I'd always
just run the fetchmail daemons from /etc/rc.local file.
On the new server:
# sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Memory protection checking: actual (secure)
Max kernel policy version: 31
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.
And, it's still not working.
I've been bashing away at this over the last few days, and this (below)
is from /var/log/messages before I changed any SELinux contexts. I've
trimmed out the completely unrelated stuff (starting of named, etc,
splattered in between). And I'm just trying this with two users at the
moment (tim and andrew), "rocky" is the hostname of the new server I'm
setting up (which is turning out to be a fateful name to give it).
Jul 8 02:08:22 rocky systemd: Starting /etc/rc.d/rc.local Compatibility...
Jul 8 02:08:22 rocky su: (to tim) root on none
Jul 8 02:08:22 rocky systemd: Created slice User Slice of tim.
Jul 8 02:08:22 rocky systemd: Started Session c1 of user tim.
Jul 8 02:08:23 rocky rc.local: fetchmail: open: /home/tim/.fetchmailrc: Permission denied
Jul 8 02:08:23 rocky dbus[1177]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper)
Jul 8 02:08:23 rocky systemd: Removed slice User Slice of tim.
Jul 8 02:08:23 rocky su: (to andrew) root on none
Jul 8 02:08:24 rocky rc.local: fetchmail: open: /home/andrew/.fetchmailrc: Permission denied
Jul 8 02:08:24 rocky systemd: rc-local.service: control process exited, code=exited status=6
Jul 8 02:08:24 rocky systemd: Failed to start /etc/rc.d/rc.local Compatibility.
Jul 8 02:08:24 rocky systemd: Unit rc-local.service entered failed state.
Jul 8 02:08:24 rocky systemd: rc-local.service failed.
Jul 8 02:08:24 rocky systemd: Removed slice User Slice of andrew.
Jul 8 02:08:29 rocky setroubleshoot: SELinux is preventing /usr/bin/fetchmail from read access on the file .fetchmailrc. For complete SELinux messages run: sealert -l f6595cf9-418b-4630-8e08-a5b0c22512ef
Jul 8 02:08:29 rocky python: SELinux is preventing /usr/bin/fetchmail from read access on the file .fetchmailrc.#012#012***** Plugin catchall (100. confidence) suggests **************************#012#012If you believe that fetchmail should be allowed read access on the .fetchmailrc file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'fetchmail' --raw | audit2allow -M my-fetchmail#012# semodule -i my-fetchmail.pp#012
Jul 8 02:08:29 rocky setroubleshoot: SELinux is preventing /usr/bin/fetchmail from read access on the file .fetchmailrc. For complete SELinux messages run: sealert -l f6595cf9-418b-4630-8e08-a5b0c22512ef
Jul 8 02:08:29 rocky python: SELinux is preventing /usr/bin/fetchmail from read access on the file .fetchmailrc.#012#012***** Plugin catchall (100. confidence) suggests **************************#012#012If you believe that fetchmail should be allowed read access on the .fetchmailrc file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'fetchmail' --raw | audit2allow -M my-fetchmail#012# semodule -i my-fetchmail.pp#012
And, now that I've made that SELinux change, if I try to make
fetchmail run from rc.local, it still doesn't work, and I get this in the /var/log/messages, which is virtually the same:
Jul 11 14:03:57 rocky systemd: Starting /etc/rc.d/rc.local Compatibility...
Jul 11 14:03:57 rocky su: (to tim) root on none
Jul 11 14:03:58 rocky rc.local: fetchmail: error opening lockfile "/home/tim/.fetchmail.pid": Permission denied
Jul 11 14:03:58 rocky dbus[1188]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper)
Jul 11 14:03:58 rocky systemd: Removed slice User Slice of tim.
Jul 11 14:03:58 rocky su: (to andrew) root on none
Jul 11 14:03:58 rocky systemd: Created slice User Slice of andrew.
Jul 11 14:03:58 rocky systemd: Started Session c2 of user andrew.
Jul 11 14:03:58 rocky rc.local: fetchmail: open: /home/andrew/.fetchmailrc: Permission denied
Jul 11 14:03:58 rocky systemd: rc-local.service: control process exited, code=exited status=6
Jul 11 14:03:58 rocky systemd: Failed to start /etc/rc.d/rc.local Compatibility.
Jul 11 14:03:58 rocky systemd: Unit rc-local.service entered failed state.
Jul 11 14:03:58 rocky systemd: rc-local.service failed.
Jul 11 14:04:03 rocky setroubleshoot: SELinux is preventing /usr/bin/fetchmail from read access on the file .fetchmail.pid. For complete SELinux messages run: sealert -l f6595cf9-418b-4630-8e08-a5b0c22512ef
Jul 11 14:04:03 rocky python: SELinux is preventing /usr/bin/fetchmail from read access on the file .fetchmail.pid.#012#012***** Plugin catchall (100. confidence) suggests **************************#012#012If you believe that fetchmail should be allowed read access on the .fetchmail.pid file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'fetchmail' --raw | audit2allow -M my-fetchmail#012# semodule -i my-fetchmail.pp#012
Jul 11 14:04:03 rocky setroubleshoot: SELinux is preventing /usr/bin/fetchmail from read access on the file .fetchmailrc. For complete SELinux messages run: sealert -l f6595cf9-418b-4630-8e08-a5b0c22512ef
Jul 11 14:04:03 rocky python: SELinux is preventing /usr/bin/fetchmail from read access on the file .fetchmailrc.#012#012***** Plugin catchall (100. confidence) suggests **************************#012#012If you believe that fetchmail should be allowed read access on the .fetchmailrc file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'fetchmail' --raw | audit2allow -M my-fetchmail#012# semodule -i my-fetchmail.pp#012
So, if I try the recommendation to look up one of those SELinux alerts
(both of which have the same code, but are on different days, so I
don't understand that) I get this:
# sealert -l f6595cf9-418b-4630-8e08-a5b0c22512ef
SELinux is preventing /usr/bin/fetchmail from read access on the file .fetchmailrc.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that fetchmail should be allowed read access on the .fetchmailrc file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do allow this access for now by executing:
# ausearch -c 'fetchmail' --raw | audit2allow -M my-fetchmail
# semodule -i my-fetchmail.pp
Additional Information:
Source Context system_u:system_r:fetchmail_t:s0
Target Context unconfined_u:object_r:user_home_t:s0
Target Objects .fetchmailrc [ file ]
Source fetchmail
Source Path /usr/bin/fetchmail
Port <Unknown>
Host rocky.lan.faked.example.com
Source RPM Packages fetchmail-6.3.24-7.el7.x86_64
Target RPM Packages
Policy RPM selinux-policy-3.13.1-229.el7_6.12.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name rocky.lan.faked.example.com
Platform Linux rocky.lan.faked.example.com
3.10.0-957.21.3.el7.x86_64 #1 SMP Tue Jun 18
16:35:19 UTC 2019 x86_64 x86_64
Alert Count 12
First Seen 2019-07-08 02:08:23 ACST
Last Seen 2019-07-11 14:03:58 ACST
Local ID f6595cf9-418b-4630-8e08-a5b0c22512ef
Raw Audit Messages
type=AVC msg=audit(1562819638.446:136): avc: denied { read } for pid=2000 comm="fetchmail" name=".fetchmailrc" dev="sda3" ino=17564575 scontext=system_u:system_r:fetchmail_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=0
type=SYSCALL msg=audit(1562819638.446:136): arch=x86_64 syscall=open success=no exit=EACCES a0=fa9600 a1=0 a2=1b6 a3=24 items=0 ppid=1995 pid=2000 auid=4294967295 uid=1006 gid=1006 euid=1006 suid=1006 fsuid=1006 egid=1006 sgid=1006 fsgid=1006 tty=(none) ses=4294967295 comm=fetchmail exe=/usr/bin/fetchmail subj=system_u:system_r:fetchmail_t:s0 key=(null)
Hash: fetchmail,fetchmail_t,user_home_t,file,read
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
Reboot, still not working, still getting similar error messages in the
log, except it's about the pid file.
Jul 11 15:01:26 rocky systemd: Starting /etc/rc.d/rc.local Compatibility...
Jul 11 15:01:26 rocky su: (to tim) root on none
Jul 11 15:01:26 rocky systemd: Created slice User Slice of tim.
Jul 11 15:01:26 rocky systemd: Started Session c1 of user tim.
Jul 11 15:01:27 rocky dbus[1154]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper)
Jul 11 15:01:27 rocky systemd: Removed slice User Slice of tim.
Jul 11 15:01:27 rocky su: (to andrew) root on none
Jul 11 15:01:27 rocky systemd: Created slice User Slice of andrew.
Jul 11 15:01:27 rocky rc.local: fetchmail: error opening lockfile "/home/andrew/.fetchmail.pid": Permission denied
Jul 11 15:01:27 rocky systemd: rc-local.service: control process exited, code=exited status=8
Jul 11 15:01:27 rocky systemd: Failed to start /etc/rc.d/rc.local Compatibility.
Jul 11 15:01:27 rocky systemd: Unit rc-local.service entered failed state.
Jul 11 15:01:27 rocky systemd: rc-local.service failed.
Jul 11 15:01:32 rocky setroubleshoot: SELinux is preventing /usr/bin/fetchmail from write access on the directory /home/tim. For complete SELinux messages run: sealert -l 4496a3d3-8655-4f1a-b1b6-287894f76f13
Jul 11 15:01:32 rocky python: SELinux is preventing /usr/bin/fetchmail from write access on the directory /home/tim.#012#012***** Plugin catchall (100. confidence) suggests **************************#012#012If you believe that fetchmail should be allowed write access on the tim directory by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'fetchmail' --raw | audit2allow -M my-fetchmail#012# semodule -i my-fetchmail.pp#012
Jul 11 15:01:32 rocky setroubleshoot: SELinux is preventing /usr/bin/fetchmail from open access on the file /home/andrew/.fetchmail.pid. For complete SELinux messages run: sealert -l 333f08f2-69bf-42cc-b69c-48dc7aac97e0
Jul 11 15:01:32 rocky python: SELinux is preventing /usr/bin/fetchmail from open access on the file /home/andrew/.fetchmail.pid.#012#012***** Plugin catchall (100. confidence) suggests **************************#012#012If you believe that fetchmail should be allowed open access on the .fetchmail.pid file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'fetchmail' --raw | audit2allow -M my-fetchmail#012# semodule -i my-fetchmail.pp#012
rm the pid files, reboot, and see what happens... Same issue...
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.
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.
---------- 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.
_______________________________________________
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
