Re: [gdm-list] [PATCH] fix race condition when setting the model for the face browser

[Brian Cameron <Brian Cameron Sun COM>]

Ludwig:

> > > - The way pictures are transported into the greeter is really ugly.
> > >   IMHO the greeter could just as well open the files itself. There
> > >   is no need to let the slave process do it.
> > Yes it is ugly.  The problem is that the GUI runs as the gdm user
> > and the gdm user does not necessarily have read access to user's
> > $HOME directory.  The daemon runs as root and has the ability to
> > read image files without these sorts of problems.
>
> If the homes are on nfs root likely gets mapped to nobody and has no
> access either. If you want anyone to access stuff in your home you
> just have to have o+x (or set an ACL for the gdm user). Apache
> doesn't read your ~/public_html if it can't walk through ~ either.
> I'm not sure how kdm handles that. IIRC it has even uglier code that
> temporarly changes the uid to the target user.

I would not be opposed to changing the way this works.  It would
probably be nicer if the GDM daemon looked around for face images
and copied them to someplace in /var/tmp where the greeters could
find them so we don't keep trying to access users $HOME directories
every time a new GUI displays.  On multihead systems (or terminal
server type environments) I'm sure the current logic works very
poorly.

> > Probably a better mechanism for passing the images from the daemon
> > to the GUI could be devised.  Perhaps the daemon should copy them to
> > a location where the GUI can find them (somewhere like /var/tmp/gdm)
> > rather than sending them over the sockets connection.
> >
> > Note GDM can be configured to use GlobalFaceDir instead of reading
> > the image files from the user's $HOME directory, but even in this
> > case I think the daemon dumbly sends the images over the wire rather
> > than having the GUI just access the images from there directly.
>
> Code for accepting file names instead of the binary image itself is
> already there though. That doesn't fix the problem that the protocol
> isn't designed for messages originating from the ui though. The
> slave requests something and the ui responds, not the other way
> around (except for interruptions).

Could you explain in more detail how the messages pass back and
forth to support the Face Browser?  Could we think of a different
way to make this work that would avoid the problem?  Is there
really a need for the GUI to talk to the daemon to display the
Face Browser?  Why can't the daemon just set up some data in a
directory like /var/tmp/gdm/facebrowser so that when the GUI
starts up it can just read some configuration files there
(and image files) and set itself up properly without having
to talk to the daemon at all?

Brian