Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Enable fingerprint login by default|
|Product:||[Fedora] Fedora||Reporter:||Bastien Nocera <bnocera>|
|Component:||anaconda||Assignee:||Chris Lumens <clumens>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||dcantrell, dmaley, fedoraproject, mclasen, rstrode, tcallawa, tmraz|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-05-12 18:04:01 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Bastien Nocera 2009-01-23 06:28:44 EST
Fingerprint login should be made available by default as: - it respects blocked and disabled accounts - it is "opt-in", the user has to enroll their fingerprints to be able to login using pam_fprintd - when no fingerprints are enrolled, pam_fprintd or fprintd aren't available, pam_fprintd doesn't do anything. - there's a large number of laptops shipping with fingerprint readers - administrator has the last word, and fingerprint login can easily be disabled system-wide. Fingerprint reading is not fool-proof, but it's one more layer the user/administrator could be enabling instead of relying on automatic logins, and no login prompt on resume from suspend.
Comment 1 Tomas Mraz 2009-01-23 06:46:13 EST
The appropriate way to enable fingerprint auth by default in a distribution is to add --enablefingerprint option to authconfig when anaconda calls it.
Comment 2 Chris Lumens 2009-01-26 13:26:31 EST
What are the downsides of adding this as a default option? Will adding --enablefingerprint fail on machines without the supported hardware? Will it set up the system such that desktop machines won't work in some way?
Comment 3 Tomas Mraz 2009-01-26 14:24:47 EST
The biggest downside is the inconsistency - authconfig does not enable any other similar option by default. Also what should happen if the module is not installed? Either it can just not add it to the system-auth configuration but what if it is installed later? Authconfig would have to be re-run but as it would be already run before the module would not be enabled automatically anyway - the option or the GUI checkbox would have to be checked. The other possibility is the current one for the command line UI - it will set it up anyway. It will not break the authentication but it will send a message to syslog for every authentication attempt. With current pam version it could be set up so it will not add this message, but it would be another inconsistency and possible source for confusion. And the first objection still applies. The third objection is from the conservative approach to security - the security of the fingerprint authentication is nothing I would rely on and so silently enabling it seems like a bad idea to me.
Comment 4 Jeremy Katz 2009-01-26 17:51:08 EST
(In reply to comment #3) > The biggest downside is the inconsistency - authconfig does not enable any > other similar option by default. Yet we don't explicitly expose authconfig during the install process and doing so seems kind of crappy as it's mostly just jargon that users will never care about. [snip] > The third objection is from the conservative approach to security - the > security of the fingerprint authentication is nothing I would rely on and so > silently enabling it seems like a bad idea to me. If you don't enroll any prints, then you won't ever get a successful match unless there's a bug; but there could be bugs in so many places that using that as an excuse is fairly ludicrous. Setting it up by default makes the hardware *work* for people who choose to use it. We just need to ensure that we do so in a way that's relatively reasonable and robust out of the box. And I really think that having authconfig just set it up by default if the module is present is the "best" way to do so rather than requiring the installer to go through contortions to figure out the version of authconfig and if fingerprint auth is supported, etc. I wonder if we're at the point where we need to be able to have packages drop in some form of "authconfig support" file and then we just end up combining those snippets... that way, if pam_fprint support is wanted, the package can just drop in the right file. And similarly for smartcards or other setups instead of relying so much on explicit calls to authconfig.
Comment 5 Bastien Nocera 2009-01-26 20:51:02 EST
(In reply to comment #2) > What are the downsides of adding this as a default option? Will adding > --enablefingerprint fail on machines without the supported hardware? Will it > set up the system such that desktop machines won't work in some way? I can only answer the second question, the rest of them being PAM specific, which Tomas is better suited to answer. Given the fprintd-pam package installed, and the pam_fprintd.so line setup in PAM (using authconfig), pam_fprintd will just fall through to the usual password authentication (or whatever else is setup) if: - there's no supported hardware - the user isn't allowed to access the hardware (setup through PolicyKit, currently only the console user is allowed to access the device) - the user doesn't have any enrolled prints - the user has been asked to authenticate, but doesn't try to authenticate within 30 seconds - the user fails to authenticate 3 times - an error occurred with the device It will not fall through if the device is physically removed. This is a bug I'll try to fix tomorrow.
Comment 6 Bastien Nocera 2009-01-27 07:37:13 EST
(In reply to comment #5) > It will not fall through if the device is physically removed. This is a bug > I'll try to fix tomorrow. Fixed in fprintd-0.1-7.git04fd09cfa.fc11
Comment 7 Chris Lumens 2009-02-20 16:45:55 EST
Does anyone have hardware they could use to test an install with this enabled? I could find some time to work on it next week if so.
Comment 8 Bastien Nocera 2009-03-04 19:32:53 EST
I can obviously test this. QE should have a (not too recent) Dell laptop with a fingerprint reader, or you can grab a Microsoft one for around $30 from most computer stores.
Comment 9 Jesse Keating 2009-04-13 20:58:29 EDT
It's a bit late to enable such a feature as this, but I'm willing to give it a go to make finger printing a better experience. Chris, do you think we could enable this tomorrow?
Comment 10 Chris Lumens 2009-04-14 09:39:44 EDT
I think this is just a simple matter of adding another flag to our authconfig line, perhaps ensuring a package is installed, and testing it. So yes, I can do this.
Comment 11 Tomas Mraz 2009-04-14 10:47:15 EDT
Note also that the new authconfig and pam packages which we have in rawhide already support writing a separate fingerprint PAM stack for GDM according to the http://fedoraproject.org/wiki/Features/MultiplePAMStacksInGDM So if fingerprint support in GDM is sufficient it should be just a matter of gdm switching on its support for multiple stacks if Ray haven't done it yet.
Comment 12 Chris Lumens 2009-04-15 14:49:36 EDT
The Base comps group contains fprintd-pam, which requires fprintd, so I think all we need to do is add the authconfig flag to complete the anaconda side of this support. I'll submit a patch.
Comment 13 Ray Strode [halfline] 2009-04-15 14:56:47 EDT
we'll also need to make sure gdm-plugin-fingerprint gets pulled in by default.
Comment 14 Chris Lumens 2009-04-16 09:37:55 EDT
The anaconda side of things should be fixed in the next build of anaconda, if you'd like to test out rawhide and see how well it works. Thanks for the bug report.
Comment 15 Bastien Nocera 2009-04-16 11:08:36 EDT
(In reply to comment #11) > Note also that the new authconfig and pam packages which we have in rawhide > already support writing a separate fingerprint PAM stack for GDM according to > the http://fedoraproject.org/wiki/Features/MultiplePAMStacksInGDM > > So if fingerprint support in GDM is sufficient it should be just a matter of > gdm switching on its support for multiple stacks if Ray haven't done it yet. We also need it for the screensaver, at least. Support for PolicyKit would have been nice...
Comment 16 Dave Maley 2009-04-16 11:43:42 EDT
*** Bug 495919 has been marked as a duplicate of this bug. ***
Comment 17 Jesse Keating 2009-05-12 18:04:01 EDT
Fingerprint reader support is indeed enabled by default.