Whoops, in retrospect I realized my solution had to do with the fact
that I symlinked the cert file or part of the path to it (hence it is
really about `lnk_file` access in that context).
But WRT posting ausearch/AVC errors, recognize these are module source
language neutral, and even if I cannot solve the problem for you I am
sure it will make it simpler and therefore more likely for someone else
to help (to refine that: throwing out a high level description of a
problem is simpler *if* someone recognizes it, which is what I responded
to -- then that is still presuming it's the same underlying cause --
otherwise, you are less likely to get a response because the pertinent
info is missing).
I'd assume that any pro level linux sys admin should be able to sort
this (otherwise, why are they considered such?), so short of that you
may need to roll up your sleeves a bit. If you haven't yet, try a
dovecot mail list as well and the fedora exchange. However, I almost
guarantee they are going to say what I am saying about the need to see
the actual AVC errors that are triggered (the tedious part then is that
clearing one may just reveal another, but it is probably not all that
complicated).
On 2026-03-24 16:58, justina colmena ~biz wrote:
> I am actually borrowing the key automatically generated by my "caddy"
> webserver for my email server as well, since it is convenient and the
> use of it is not restricted.
>
> Not the best general purpose use case, though, and in most cases it is
> quite proper for SELinux to restrict access to those files.
>
> Intentionally doing something that is not or should not normally be
> allowed will require exceptions.
>
> The ".cil" is very simple, low level, arcane yes, but one step, rules
> module immediately named, applied and enforced. There is some priority
> assigned to the new module whether the custom local rules should
> override other system wide rules or not.
>
> Apparently there are different languages in which policy modules may
> be written. Or maybe something is "deprecated" and I'm just not aware
> of it.
>
> Read access and sometimes x permissions for the full path to the
> desired file also need to be enabled. It's a human time management
> issue how deep to delve into something technical, and determine
> whether one is accomplishing something useful or beneficial or
> profitable or perhaps working at cross purposes to others in the
> community who might have conflicting goals and objectives. Your own
> domain name being an open acknowledgement of that.
>
>
> On March 24, 2026 10:34:56 AM PDT, "Mark E."
> <mk(a)cognitivedissonance.ca> wrote:
>
> I have dovecot and postfix running on an F42 server and did have
> to do a bit to get at least dovecot reading the certs. I never
> work with .cil stuff though, I think this is generally considered
> more arcane and awkward than the .sel -> .mod-> .pp route.
>
> Can't say whether this will work on F43 since you did not post
> actual ausearch/AVC errors (probably you should lead with those):
>
>
> module dovecot_read_cert 1.0;
> require {
> class lnk_file { read };
> type init_t, dovecot_cert_t;
> }
> allow init_t dovecot_cert_t:lnk_file read;
>
>
> Save that as dovecot_read_cert.sel and:
>
> checkmodule -m -o dovecot_read_cert.mod dovecot_read_cert.sel
>
> semodule_package -o dovecot_read_cert.pp -m dovecot_read_cert.mod
>
> semodule -i dovecot_read_cert.pp
>
>
> You can then delete the .pp and .mod files. Pretty sure I got
> most of the syntax etc. from "SELinux System Administration" by
> Sven Vermeulen, if you want a book recommendation, although I
> think there are quicker ways of doing this now, eg. `ausearch -m
> avc -t recent | audit2allow` will generate .sel syntax you can
> cherry pick into a module as above (but you have to intuit the
> `require {}` section).
>
>
> Again, posting the raw audit/ausearch output is probably the
> fastest way to get help.
>
>
> On 2026-03-23 16:17, justina colmena ~biz via selinux wrote:
>>
>> With SELinux in enforcing mode on a remote server, writing policy
>> files, I am using commands like "ausearch -ts recent" and
>> "semodule -i local_policy.cil".
>>
>> The file has a "lisp" syntax I can't really find documented
>> anywhere, and this is a hammer-and-nails approach for a lot of
>> stuff on the "targeted" policy that probably should be allowed
>> but is not or was not allowed by default. Of course, you really
>> do not want any of this stuff unless there's a specific reason
>> you do want it.
>>
>>
>> Failure is not an option, and there is not really a good way to
>> recover if anything goes wrong.
>>
>>
>> I had previously followed a lot of tutorials to enable SELinux on
>> Fedora 41, and the upgrade proceeded without incident except that
>> dovecot and postfix failed to read the SSL certificates and keys
>> because of AVC denials, and the configuration files for dovecot
>> had totally changed in format.
>>
>>
>> local_policy.cil:
>> (allow postfix_smtpd_t var_lib_t (file (getattr open read)))
>> (allow httpd_t unconfined_service_t (unix_stream_socket
>> (connectto)))
>> (allow init_t mysqld_port_t (tcp_socket (name_connect)))
>> (allow init_t soundd_port_t (tcp_socket (name_connect)))
>> (allow init_t http_port_t (tcp_socket (name_connect)))
>> (allow init_t user_home_t (file (getattr open read write append
>> create
>>
>> rename execute execute_no_trans lock)))
>> (allow init_t user_home_t (dir (getattr search)))
>> (allow init_t user_home_t (lnk_file (read)))
>> (allow postfix_smtpd_t postfix_data_t (file (getattr open read write
>>
>> append create rename execute execute_no_trans lock)))
>> (allow postfix_smtpd_t postfix_data_t (dir (getattr search)))
>> (allow postfix_smtpd_t postfix_data_t (lnk_file (read)))
>> (allow init_t io_uring_t (anon_inode (create map read write)))
>> (allow init_t self (process (execmem)))
>> (allow saslauthd_t saslauthd_t (capability (dac_read_search)))
>> (allow saslauthd_t saslauthd_t (file (getattr read)))
>> (allow saslauthd_t saslauthd_t (dir (getattr search)))
>> (allow saslauthd_t saslauthd_t (lnk_file (read)))
>>
>>
