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