per seat hardware and login managers

David Zeuthen david at fubar.dk
Mon Mar 19 20:04:23 PDT 2007


On Mon, 2007-03-19 at 16:04 -0400, William Jon McCann wrote:
> Hi,
> 
> While patching pam thinkfinger [1] to work without root privilege I
> realized that there is a use case for per seat hardware beyond the
> typical multi-seat case.  I think it is worth discussing how we expect
> to handle it.
> 
> In brief, the case is this:
> 
>  * Computer A has a biometric/fingerprint/smart card device.  It has
> PAM configured to allow authentication by this device.
> 
>  * Computer B connects to Computer A via XDMCP (or other means).
> 
>  * The login manager (GDM/login/etc) on Computer A displays a login
> prompt to Computer B.
> 
>  * The user at Computer B does not have physical access to the
> hardware of Computer A.
> 
> And the specific question is: How should a PAM module running on
> Computer A know what "seat" it is attached to?
> 
> And the reason why this is a slightly different question than (after
> login) what seat does the new session belong to is that at the moment
> login managers do not run in a session and the resulting user session
> is created after authentication.
> 
> The answer will also be relevent to how we might run things like
> gnome-power-manager while a login manager is running.
> 
> One possible solution is to run the login manager in its own (possibly
> special) session.

I think we need to just do this; in many ways it is indeed it's own
session and it would reduce ugly things like this

 http://cvs.fedora.redhat.com/viewcvs/devel/gdm/90-grant-audio-devices-to-gdm.fdi?rev=1.1&view=auto

to just being normal policy because right now gdm can always access your
sound devices... (not a huge attack vector but a bit annoying
nonetheless).

     David




More information about the hal mailing list