Bug 481273

The appropriate way to enable fingerprint auth by default in a distribution is to add --enablefingerprint option to authconfig when anaconda calls it.

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?

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.

(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.

(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.

(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

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.

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.

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?

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.

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.

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.

we'll also need to make sure gdm-plugin-fingerprint gets pulled in by default.

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.

(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...

*** Bug 495919 has been marked as a duplicate of this bug. ***

Fingerprint reader support is indeed enabled by default.