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

[Ludwig Nussel <ludwig nussel suse de>]

Brian Cameron wrote:
> 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.

Does the face browser really need to be optimized for that use case?
If there are too many users the face browser isn't of much use
anyways. KDM on SUSE for example displays up to seven users. If
there are more users in the system it displays the seven most
recently logged in ones instead.

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

Well, you are the maintainer of GDM. Don't ask me how or why it
works the way it works :-)

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

That's what I am wondering too.

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

You'd have to maintain that cache directory somehow so that if a
user changes the image the cache gets udpated as well. That's
overkill for little gain. IMHO custom images are just a gimmick for
home users which means low number of users and local home
directories. So the most simple way to read the images is to just
access the file in the home directory directly as user gdm. If gdm
is not allowed to access the file then so it be.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   SUSE LINUX Products GmbH, Development
 V_/_  http://www.suse.de/