On Sat, 2019-07-13 at 08:10 +0800, Ed Greshko wrote:
In the event anyone is interested. The short answer is....
Unless a file or directory has a "FILE transition rule" defined in
the selinux policy it will inherit the context of the directory where
it resides. The file .fetchmailrc has no such transition rule
associated with it.
Hmm, I thought one of the prior posts said that .fetchmailrc needed a
special context (it's certainly different from the home user's other
contexts). A further problem was that running fetchmail created a
.fetchmail.pid lock file that apparently needed special context, too.
$ ll -Z .fetchmail*
-rw-------. tim tim unconfined_u:object_r:user_home_t:s0 .fetchmail.pid
-rw-------. tim tim unconfined_u:object_r:fetchmail_home_t:s0 .fetchmailrc
This (above) worked when called by root in the command line, the user
in the command line, or crontab, but not from rc.local.
Inheriting *my* home directory context wouldn't get it working in the
case I was trying (from rc.local):
$ ll -Zd /home/tim
drwx------. tim tim unconfined_u:object_r:user_home_dir_t:s0 /home/tim
Since I was launching fetchmail with "su" in front of it, it ought to
be running as me. Which, normally, wouldn't have suffered all the
problems I was having with it.
I even tried changing the command further, to use my environment:
su --login tim -c "/usr/bin/fetchmail -d 900"
Which also fails, but with even less useful information in the logs
(zero mention of fetchmail).
I even tried making a /etc/fetchmail script, containing my commands,
and launching that script from rc.local, instead. Still didn't do me
any good.