Re: [gdm-list] how to use authentication feature of GDM in a screen saver

[Ray Strode <halfline gmail com>]

Hi,

On Fri, Apr 9, 2010 at 11:00 AM, Oswald Buddenhagen <ossi kde org> wrote:
> hi,
>
> On Fri, Apr 09, 2010 at 08:06:49AM -0400, Ray Strode wrote:
>> On Thu, Apr 8, 2010 at 5:33 PM, Oswald Buddenhagen <ossi kde org> wrote:
>> > a "sticky" factory server might be a tad expensive resource-wise.
>>
>> It's a trade off I guess. I think it's probably okay to start early.
>> I mean, if it was so expensive it mattered, then fast user switching
>> wouldn't be practical.
>>
> well, yeah, it's probably way less than a "proper" second session, but
> it is still a lot of (virtual) memory. it would matter particularly on
> the systems where the fast user switching is usually not used, i.e.,
> it is just overhead there.
True, it's just extra overhead for a user who doesn't fast user
switch.  We could do some heuristics based on ck-history or something
to decide whether to show the factory.

>> > in any case i see two fundamental problems:
>> > - there *may* be pam modules which can't deal with PAM_XDISPLAY not
>> >  belonging to the actual session
>>
>> We set PAM_XDISPLAY ourselves, so we can just make sure we set it to
>> the spawned X server (we probably don't get that right at the moment
>> though)
>>
> that's besides the point. a module may naively assume that it can
> somehow talk to windows in the session via that display. of course
> that's a bit constructed, so it's not too much of a worry for now.

Well, it's a little dubious for a pam module to be creating and
showing windows to the user without any sort of coordination with the
thing having the pam conversation.  It's sort of doomed to failure.  I
think PAM_XDISPLAY is mainly useful for xace and "under the covers"
type things, not for interacting with the user.

>> > - if there is only one screen saver server, who gets to configure the
>> >  it? :-D
>> >  no, seriously. some users will complain if only root can configure
>> >  "their" screen saver. this is only an issue for actual multi-user
>> >  systems, of course.
>>
>> We could keep the screensaver part on the session vt, and have the
>> unlock part on the factory vt.
>>
> hmm. the kde screenlocker (possibly only in relation with the kde window
> manager) is having some serious trouble with actually securing the
> display
Yea that's a real problem, because anyone can old on to the pointer
and keyboard grabs and prevent screen lock from activating.  I don't
think this proposal addresses that problem though, since we need the
screen locked on the other X server regardless (otherwise the user
could just hit ctrl-alt-f8 or whatever and get at the unlocked
display).

> ... there are issues with passive notifications popping up above
> it,
gnome-screensaver has this issue too.  I think making the screensaver
windows be children of the MIT screensaver window would help here.
It's a long time todo item for me. I wrote a blog post about it here:

http://blogs.gnome.org/halfline/2007/07/25/screensaver-extension/

Another option would be to have the compositor (e.g. gnome-shell)
manage drawing the screensaver.  Since the compositor already draws to
an always on top overlay window it could just do the right thing.
Doing it that way also has the distinct advantage of paving the way
toward fixing the "remote login with vino" bug:

https://bugzilla.gnome.org/show_bug.cgi?id=311780

> what we actually would want is some kind of in-server context switch.
> a server grab won't cut it, as the greeter may need to start secondary x
> clients. i wonder whether x-ace caters for that?
Server grab won't cut it anyway because it means that all other
clients will block when they try to talk to X and then they'll sit
their frozen.  If they're frozen they're not dealing with other
important things.  It could break music players, time out pending
downloads, disconnect the user from IRC, stall long running copy
operations or whatever else.

I agree it would be good to have better infrastructure than what we
have for screen lockers in XFixes or whatever, but I'm not exactly
sure what that better infrastructure would be.  Maybe it could just be
two things:

1) A new kind of grab that supersedes pointer and keyboard grabs
(XGrabInputDevices ?), without taking other clients out of the
server's select() loop like XGrabServer

2) an api that lets one client atomically transfer grab ownership to
another client

>> > but i wonder whether one should get straight into that mode or
>> > whether it should be reached via a separate menu point from a more
>> > classical "user bound" screen lock.
>>
>> If the factory is already running, doing the switch immediately
>> probably makes sense, since it should be quite fast.
>>
> i wasn't wondering so much about speed (yet). it's a general user
> interaction question.
If speed isn't an issue, it's clearly better to not have a dialog that
asks if you want to go to the real dialog.

--Ray