Hi, On 3/4/21 11:50 AM, Pavel Březina wrote: > On 3/3/21 6:11 PM, Hans de Goede wrote: >> Hi, >> >> On 3/2/21 5:20 PM, Pavel Březina wrote: >>> On 3/2/21 4:25 PM, Ray Strode wrote: >>>> Hi, >>>> >>>> Ahh, okay. >>>> >>>> On Tue, Mar 2, 2021 at 9:31 AM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: >>>>> sudo authselect select minimal >>>>> sudo authselect apply-changes >>>>> >>>>> Which results in the following /etc/pam.d/fingerprint-auth file: >>>>> >>>>> [hans@x1 linux]$ sudo cat /etc/pam.d/fingerprint-auth >>>>> # Generated by authselect on Tue Mar 2 15:24:53 2021 >>>>> # Do not modify this file manually. >>> >>> minimal profile does not support fingerprint >> >> So it seems there are 4 profiles: >> >> [hans@x1 ~]$ authselect list >> - minimal Local users only for minimal installations >> - nis Enable NIS for system authentication >> - sssd Enable SSSD for system authentication (also for local users only) >> - winbind Enable winbind for system authentication >> >> What I want is a profile which uses just the good old /etc files to >> avoid the overhead of running a local daemon (sssd tends to show up as >> one of the top 10 wakeup sources in powertop on an idle system) and I >> also don't want a config which tries to go out on the network. >> >> So minimal seems to meet my needs; and although I personally do not >> have much of a need for fingerprint auth, I don't really see why we >> could not do fingerprint auth with the minimal config. I'm pretty > > I'd say the answer is simple - if you go with minimal, you don't need fingerprint. And you wrote it yourself - you don't need fingerprint auth. Just because something can be done, does not mean it is worth to maintain it. More info below. > >> sure I can manually create a pam-config where this works just fine. >> >> I guess its in the name minimal, where as "local" might be (1) a better > > That's the point - it's minimal not local, not without-sssd. The readme explicitly says that it reserved for cases when you really care about disk and memory footprint. > > It has very limited functionality by design. If you do not want to use SSSD, you can keep using sssd profile and just disable the service. It will keep working. The minimal profile is there for users that also want to remove sssd packages to safe resources, but in that case you probably don't care about fingerprint and smartcards either. The problem is that IMHO having sssd enabled by default is really the wrong thing to do for like 95% of our users and defaults should be the settings which are best for most / almost all users. This is really just a symptom of a much bigger problem though, which is that we simply have way too much services / daemon's starting up by default. The output of "ps aux" after a default Fedora workstation install is just way way too long. Once upon a time Linux users used to make fun of Windows with all its background processes in the mean time a default Fedora WS install has gotten worse then Windows wrt background processes. Any of these are totally unnecessary for most of our users. We really should be smarter here and the config tools which allows a user to enroll in an authentication domain enable the sssd config when that happens and not have this on by default for everyone. So what I would really like to see is a local profile which uses just /etc files + fprintd if there are fingerprints enrolled. Smartcards are a different story, because those likely also need significant extra setup. Where as fingerprints can easily be enrolled from the local UI tools. >> name. Note I'm not suggesting to add another profile just for this >> but it would be nice if fingerprint auth would at least be a >> (default off) feature for the minimal config. >> >> Shall I file a RFE issue for this at: >> https://github.com/authselect/authselect/issues/ > > If you need fingerprint auth then open the ticket please - but no promises here. If you don't need it then just don't open the ticket :-) Rather then opening a ticket, what I would really like to see is a good discussion about why the sssd profile is the default, because IMHO it is a bad default for most users. Regards, Hans _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
