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

[Oswald Buddenhagen <ossi kde org>]

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.

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

> > - 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 ... there are issues with passive notifications popping up above
it, people want stupid plasma gadgets which open the door for all kinds
of data leaks (clipboard, etc.).
of course the issues remain for non-local displays in the first place,
so they should be fixed nonetheless ... if possible.

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?

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