Re: running Gnome apps on an ssh session

[Kenny Hitt <kenny hittsjunk net>]

Hi.  I'm not sure I understand all the problems, but I think a per
display solution would be best.  I don't allow root logins from gdm or
ssh.  This  means I need to run some form of su after login.  I've
already noticed I can't do admin tasks even on the box I have physical
access to because I loose accessibility info after the "su -" command.
One other possible benefit of using a per display approach would be
allowing a teacher to see what was happening with a student.
I'm still learning about X, but I thought two users with the same
privileges couldn't access each other's X display.

          Kenny

On Sat, Jan 22, 2005 at 09:51:30PM +0000, Bill Haneman wrote:
> Kenny asked:
> 
> >Hi.  Is this documented in bug reports?  If not, what packages need bug
> >reports filed against them?
> > 
> >
> I've filed RFEs 164941 for bonobo-activation (remote activation) and 
> 164942 for at-spi (remote application communication with 
> at-spi-registryd).  The two are inter-related.
> 
> There are some interesting questions raised here, and it's not entirely 
> obvious what the best approach is.  We could, for instance, move away 
> from bonobo-activation for the registry, and use an X-display-based 
> technique such as stringifying the IOR in an X atom in order to locate 
> the appropriate at-spi-registryd instance.  This would turn our 
> per-user/host AT-SPI registry into a per-DISPLAY registration - however 
> there may be some security implications in doing so. 
> 
> The issue of what to do about applications sharing the same display, but 
> owned by different users, is even trickier, and arises when, for 
> instance, a user runs an application which needs root privilege, such as 
> the set-date-and-time utility.  Some such applications run the GUI as 
> root too, which prevents them from connecting with the user's at-spi 
> registry.  In general, one doesn't want other users to have access to 
> one another's accessibility APIs because it violates the usual 
> user-based security model - particular when they may be running as root.
> 
> Bill
>