Re: xscreensaver, any plan do drop it !!
- From: "John (J5) Palmieri" <johnp redhat com>
- To: William Jon McCann <mccann jhu edu>
- Cc: desktop-devel-list gnome org, Bastien Nocera <hadess hadess net>
- Subject: Re: xscreensaver, any plan do drop it !!
- Date: Wed, 06 Jul 2005 12:01:11 -0400
Hi William,
It does indeed seem that you have address many of our concerns with
respect to the screen saver. Bastien filled me in. We are going to
discuss including it in Fedora today and will most likely get some test
packages and play around with it and give you feedback.
On Wed, 2005-07-06 at 11:28 -0400, William Jon McCann wrote:
> Hello John,
>
> John (J5) Palmieri wrote:
> > Some people had some problems with it becoming a replacement. Not sure
> > what they were and I haven't investigated it myself.
>
> I encourage you and others to actually look at how I've been trying to
> design gnome-screensaver. I am eager to receive specific feedback.
>
> > Has it been vetted
> > yet for security issues? The biggest problem with xscreensaver type
> > locking is that if xscreensaver crashes your session is unlocked. This
> > is why the author didn't want to link against external libraries if it
> > could be avoided (and why we get ugly dialog). Replacing it with
> > something else doesn't really solve any problems other than making it
> > look better. I think we need to get GDM to start doing the locking.
> > That way if it crashes the session exits. If we do that then we can use
> > anything for a screensaver app.
>
> I'll agree with you in principle that failing closed is better than
> failing open. However, failing closed with data-loss and disruption not
> an ideal solution (except for security experts and TSA employees). Talk
> to angry users who have been logged out and lost work. Of course, this
> argument applies equally to xscreensaver and gnome-screensaver.
>
> It is not true that using a toolkit for the lock dialog requires linking
> to toolkit libraries. I think I've solved this problem adequately by
> running the authentication checking and lock dialog code in a separate
> process that is embedded in the window using XEMBED. I decided to use
> GtkSocket for this, on the daemon side. It should be possible to do
> exactly the same thing using only Xlib. I have chosen not to duplicate
> code and also acknowledge that most likely I could not do it better than
> GTK+ does. Obviously, a trade-off.
>
> Using a separate process for the input processing, authentication, and
> non-trivial widgetry is a big win in terms of security.
>
> Replacing the input dialog is only one of the many goals of
> gnome-screensaver and not one of the most important ones. It is more
> important that gnome-screensaver allows a system administrator to set
> mandatory policy for screensaver themes and locking. It is difficult to
> talk about system security when any any user can disable the screensaver
> altogether or use a theme that displays porn and the system
> administrator can't do anything about it. On the other hand, some
> systems require that the screen never be locked. Setting this kind of
> policy is impossible to do with xscreensaver.
>
> Currently, gnome-screensaver uses GConf for settings and policy. At the
> moment this requires it to link to the GConf libraries. The use of
> GConf is an implementation detail to gnome-screensaver. It is hidden
> within the GSPrefs object. I think it should be possible to use some
> kind of proxy object via DBus to get these settings and changes. I am
> not familiar enough with DBus to know how one can up a trust
> relationship between two objects. Since it is important that the
> settings come unaltered from GConf I have decided (for now) to link
> directly to the GConf libraries.
>
> gnome-screensaver is about a lot more than "making it look better."
> Let's try to move the conversation past that point.
>
> I've tried to put some information in the Wiki:
> http://live.gnome.org/GnomeScreensaver
>
> I'll be happy to try to answer any specific questions and criticism.
>
> Thanks,
> Jon
--
John (J5) Palmieri <johnp redhat com>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]