Update: Watching the journal during server install, you see it littered with hundreds of pcscd complaints about both dirsrv and pkiuser, followed by errors in freeipa related to that. (Seems related to installing dns with the server ??)

instead of adding pkiuser to the wheel group noted above, consider this a work-around until someone who actually knows about why you can't get the smart card reading system to just say 'nothing' to anything that asks when there are no smart card readers installed.

create /etc/polkit-1/rules.d/00-allowpkiuser.rules with

polkit.addRule(function(action, subject) {
    if ((action.id == "access_pcsc") &&
       ((subject.user == "pkiuser") || (subject.user == "dirsrv"))) {
            return polkit.Result.YES;
    }
});

It didn't entirely fix the problem. I had to remove pcsc-lite, opensc, pcsc-lite-ccid

Are there any tokens visible to pcsc? Are they initialized with a PIN?

Are you getting SELinux denials as well?

@cipherboy FYI

@jmagne would be the right contact here.

re: SELinux-- I'm sorry to say so but, because of the transient not-so-tested frequently-update nature of fedora and the fact SELinux appears to be late and low on every developer's list of things to check: There are so many AVC denials that pop up that break one component of dns or ipa I've just gone 'permissive' to get anything material working for more than an hour.

There are so many components to freeipa that are maintained by so many non and partly overlapping groups of developers and testers I've come to the rather pragmatic view the way to go re: SELinux is to put everything about freeipa in a virtual machine (not container) and run it in a safe sandbox, exercise all the major functions, accumulate a log full of AVC denials, then audit2allow -a, load that policy, and reboot and repeat until there are no denials for a day -- then go so to speak 'live' with that image.

-HC

In general I can't recommend your approach.

IPA works very hard to be work on concert with SELinux, going so far as to provide its own policy. If you run into AVCs we'd appreciate if you could file issues on them.

I looked at your example in the original report and in that case it's the 389 (dirsrv) user that isn't allowed to access pcscd, not pki.

You are correct, dirsrv is one of the two users complained of in voluminous fashion. The other was pkiuser.

However, I think the problem is deeper than just the polkit aspect. The polkit feature fixed most of the complaints, but as you can see not all of them.

In the end, I had to remove the smart card subsystem from fedoraworkstation in order to get pki-tomcatd running.

re: SELinux, I don't 'recommend' my approach either. However the accumulation of so many AVC's from so many distinct packages to include even the kernel (virtiofs... / dax) at times just to move ahead on development calls for a working system. Waiting for AVC fixed, noting new ones arrive with almost every 'dnf ugprade' -- in order for development and testing to proceed would add literally a couple years to the project.

Here's a sample from a freeipa-server install with dns just a minute ago:

Feb 11 15:14:34 registry1.1.quietfountain.com named[1291]: zone 1.quietfountain.com/IN (signed): could not get zone keys for secure dynamic update
Feb 11 15:14:34 registry1.1.quietfountain.com named[1291]: zone 1.quietfountain.com/IN (signed): serial 1613078074 (unsigned 1613078074)
Feb 11 15:14:34 registry1.1.quietfountain.com named[1291]: resolver priming query complete
Feb 11 15:14:36 registry1.1.quietfountain.com named[1291]: zone 1.quietfountain.com/IN (signed): sending notifies (serial 1613078074)
Feb 11 15:14:38 registry1.1.quietfountain.com [4660]: GSSAPI client step 1
Feb 11 15:14:38 registry1.1.quietfountain.com [4660]: GSSAPI client step 1
Feb 11 15:14:38 registry1.1.quietfountain.com [4660]: GSSAPI client step 1
Feb 11 15:14:38 registry1.1.quietfountain.com audit[1291]: AVC avc:  denied  { write } for  pid=1291 comm="isc-worker0000" name="quietfountain.com" dev="virtiofs" ino=293889 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=1                                                                                 
Feb 11 15:14:38 registry1.1.quietfountain.com audit[1291]: AVC avc:  denied  { add_name } for  pid=1291 comm="isc-worker0000" name="tmp-aT7XC6IKq3" scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=1                                                                                                           
Feb 11 15:14:39 registry1.1.quietfountain.com audit[1291]: AVC avc:  denied  { remove_name } for  pid=1291 comm="isc-worker0000" name="tmp-aT7XC6IKq3" dev="virtiofs" ino=295471 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=1

FYI, this issue is basically the same thing as https://bugzilla.redhat.com/show_bug.cgi?id=1928154 but just with different component.

Note, that the action_id from your snippet needs to be the full name "org.debian.pcsc-lite.*" instead of just "access_pcsc". You can get more logs from polkit with some custom rules like and restart polkit to get more information what subject is executing the process

polkit.addRule(function(action, subject) {
if (action.id == "org.debian.pcsc-lite.access_pcsc" ||
action.id == "org.debian.pcsc-lite.access_card") {
polkit.log("action=" + action);
polkit.log("subject=" + subject);
}
});

jjelen: Thanks! Your hint plus a bit generated a fix included below. It allowed a slightly later version of freeipa-server (freeipa-server-4.9.2-4.fc33.x86_64) to install, instead of freeipa-server installation failing owing to timeouts starting pki-tomcatd@pki-tomcat

Without your help, freeipa-server install reports:

2021-03-14T23:02:46Z DEBUG The ipa-server-install command failed, exception: CalledProcessError: CalledProcessError(Command ['/bin/systemctl', 'start', 'pki-tomcatd@pki-tomcat.service'] returned non-zero exit status 1: 'Job for pki-tomcatd@pki-tomcat.service failed because a timeout was exceeded.\nSee "systemctl status pki-tomcatd@pki-tomcat.service" and "journalctl -xe" for details.\n')
2021-03-14T23:02:46Z ERROR CalledProcessError(Command ['/bin/systemctl', 'start', 'pki-tomcatd@pki-tomcat.service'] returned non-zero exit status 1: 'Job for pki-tomcatd@pki-tomcat.service failed because a timeout was exceeded.\nSee "systemctl status pki-tomcatd@pki-tomcat.service" and "journalctl -xe" for details.\n')
2021-03-14T23:02:46Z ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information

With the fix below, freeipa-server installs (still p11 issues with getting DS keys out of opendnssec and into named though).

I suggest the freeipa-server devs consider adding the file below to the server install process. I kept your log notions to report failures because there's certain to be other daemons that fail for this reason going forward; might as well save the next person some time getting to this bug report and likely resolution.

/etc/polkit-1/rules.d/00-allowpkiuser.rules:

polkit.addRule(function(action, subject) {
if (action.id == "org.debian.pcsc-lite.access_pcsc" ||
action.id == "org.debian.pcsc-lite.access_card") {
if ((subject.user == "pkiuser") || (subject.user == "dirsrv")) {
return polkit.Result.YES;
}
polkit.log("action=" + action);
polkit.log("subject=" + subject);
}
});

Let's add 'named' to the mix as denial pops up in the logs as well (re dnssec)

polkit.addRule(function(action, subject) {
if (action.id == "org.debian.pcsc-lite.access_pcsc" ||
action.id == "org.debian.pcsc-lite.access_card") {
if ((subject.user == "pkiuser") || (subject.user == "dirsrv") || (subject.user == "named")) {
return polkit.Result.YES;
}
polkit.log("action=" + action);
polkit.log("subject=" + subject);
}
});

The underlying causes related to a freeipa pull request, the details are here:
https://pagure.io/freeipa/issue/8757