[675] in athena10
Re: GDM Greeter Custom Commands
daemon@ATHENA.MIT.EDU (Quentin Smith)
Tue Dec 2 21:34:14 2008
Date: Tue, 2 Dec 2008 21:33:29 -0500 (EST)
From: Quentin Smith <quentin@MIT.EDU>
To: Greg Hudson <ghudson@mit.edu>
cc: athena10@mit.edu
In-Reply-To: <1228270597.6941.17.camel@ray>
Message-ID: <Pine.LNX.4.64L.0812022131300.19068@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Tue, 2 Dec 2008, Greg Hudson wrote:
> For the specific purpose of running the registration applet on cluster
> machines, I would suggest looking into the kludge of having the applet
> wrapper script discover the display information.
I think it would be nice if we could support registration on private
workstations as well, but I guess that's a decision to be made by
release-team.
> I believe you can do this by peering at /var/lib/gdm. On my machine, it
> contains a file named :0.Xauth. So :0 is the display and that file is
> the xauth cookie.
>
> (/var/lib/gdm is only readable by root. I assume that in the course of
> a normal login, gdm copies the xauth cookie into a location readable by
> the user logging in. The registration applet wrapper would presumably
> copy the cookie into a temporary directory owned by user nobody and then
> su to nobody and fork off the appropriate program.)
/var/lib/gdm has gid gdm, and the greeter runs as gid gdm. I don't think
you want to spawn any untrused X apps on the console, even if they're
running as nobody, because there are X calls that could be used to elevate
its privileges.
I believe that X supports "untrusted" connections and there is a mechanism
for generating an untrusted xauth file, but I suspect java wouldn't be
supported.
I would suggest a better architecture would be for the "register" button
to actually log in as a special "register" user that runs the registration
applet. That way, we follow gdm's normal session security model.
--Quentin
