On 7/12/19 10:49 PM, Tim via users wrote:
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.
That's what he said. By default, the file will have the same context as
your home directory. But that is wrong in this case. You can see that
because running restorecon changes the context. There are no rules for
the .pid file at all. Fetchmail needs to be able to create that file in
the home directory and be able to read it.
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
Right, that's the problem. It needs a rule so that it gets created with
the right context instead of you having to fix it.
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.
It's running as your id, but it's also running in the fetchmail_t
selinux execution context.
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.
It doesn't matter what you do. If fetchmail is run from init, it will
be restricted by the execution context.
The temporary workaround is to run "semanage permissive -a fetchmail_t"
which stops selinux from enforcing the restrictions.
_______________________________________________
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
