Re: xscreensaver, any plan do drop it !!

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:

I'll be happy to try to answer any specific questions and criticism.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]