GNOME.org
 

Re: New modules in 2.14

Hi Ryan,
I should point out that I can't speak for Richard, or David and these are merely my interpretations of their work. 

Ryan Lortie wrote:

On Wed, 2006-18-01 at 10:32 -0500, William Jon McCann wrote:


How is a system daemon more secure than a user session daemon?


A system daemon runs as root (or some other 'special' user) and can be
given special abilities without giving them to the user.  A system
daemon is also immune to user tampering.
User tampering? You mean like pulling the power cord? This is pretty silly. Clearly, in a system that requires strict lockdown you won't be using user controlled power management. 

Using an out-of-session daemon has a number of disadvantages:

 * I think it is harder to write securely.
 * Policy would still have to be defined in the session.
* You also need to provide a mechanism for the user session to communicate policy. * You still have to figure out which session is on console in order to arbitrate policy choices. 
 * You have to determine which session is allowed to invoke actions.
* Something in the user session still has to trigger a shutdown, suspend, or hibernate. 
 * Need a way to communicate feedback, notifications, etc to the user.
So, in the end, the session still has the ability to perform power management actions and the "who's on console" issue is not solved. 

I think the who's in control of the console issue is larger than g-p-m.
g-p-m doesn't require any additional privileges. HAL is doing most of the work. 

This is exactly the problem.  In order for g-p-m to do its stuff we have
to add to HAL the ability for any user to say "suspend the system
now" (since g-p-m needs to do this and it's just running as a normal
user).  If any user can say "suspend now" then I can be logged in as a
background user and play nasty tricks on the console user.  HAL
currently has no mechanism for making a distinction between background
users and the user that currently 'controls' the machine.

When you add additional privileges to HAL you also increase the chance
that someone is able to exploit a security hole in HAL itself.  Martin
Pitt, for example, has ranted about this at length because it's not a
good idea (and even found some security problems to validate his
concerns).


This seems like a general argument against HAL and not g-p-m in particular.
Can you please provide some reasons why g-p-m is "very Gnome-centric"? It uses the system tray standard and provides a DBUS interface that any application can use. This DBUS interface could be standardized with freedesktop.org once we figure out what works for us. Yes, it has GNOME in its name and uses Gconf and GTK+. 

You provided my reasons for me.  You could say that all Gnome
applications are sufficiently cross-desktop because they connect to the
X server through the standard protocol.  They do not, however, have the
Qt look and feel so they stick out like a sore thumb.  KDE users are
also not interested in having Gconf and GTK+ installed.  For this
reason, you can't honestly expect KDE to use g-p-m.
Oh, come on. So, you're referring to the preferences dialog only? I think there are two equally simple ways to solve this (if you care). Write a policy abstraction that can get from either GConf or the KDE equivalent and make a preferences dialog in Qt, or write a kde-power-manager that uses the same DBUS interface.
Adding an application to the Desktop release doesn't make too many guarantees about its API availability. 

We talked about this in #gnome-hackers a bit before I wrote my mail
listing my concerns.  Jeff (I think!) brought up the example of esd and
said that it's very hard to remove something once it's included.  Once
apps start to depend on it it -does- become difficult to remove.
That doesn't mean it must always be the case. Again, the application is not nearly as important as the DBUS API. 


Another issue is that right now some distributions are using power
management systems that are vastly different from how g-p-m works.  If
we include g-p-m we are encouraging people to depend on it and making
life difficult for those distributions that do not want to ship it.
I think it is the interface that counts. As long as the DBUS interface is sane then you should be able to plug whatever you want in to provide that service. 

g-p-m is a session daemon.  It uses the D-BUS session bus and does not
listen on the system bus.  Most distributions have power management
systems that run at the system level.  It's difficult for things not
running as part of the user's session to connect to the user's session
bus (in fact, the default policy is to reject non-user connections -
even those from root).  You also have to somehow 'snoop' the bus
location out of the environment of another process.  You also assume
they use D-BUS for their systems at all (or want to).
I don't understand your reasoning here. Are you assuming that the system isn't using HAL?
The question comes down to: is there sufficient reason not to use the best solution we have in favor of one that hasn't been spec'd, reviewed, or developed in the community or at all? 

For what it's worth, Davyd Madeley spec'd this imaginary system out a
long time ago.  Of course, nobody has coded on it.
I don't know about that. However, I have read David Zeuthen's spec and I think that is what the existing gnome-power-manager has been based on: 

http://mail.gnome.org/archives/utopia-list/2005-April/msg00002.html

I think it is very well thought out and it seems to work.


A lot of your argument has been along the lines of "including g-p-m now
doesn't limit the choice of distributors or our future choices".  Based
on what I've been told, I think that in a very real way it limits both
of these things.  This makes sense -- if Gnome applications start to use
g-p-m then it becomes hard to remove (both for distributions and for us
in the future).
If someone comes up with something better, I'm confident that people will use it.
The "who's in control of the console" issue does indeed need to be solved. I'm aware of a few promising possibilities, there may be more: 
http://bugzilla.gnome.org/show_bug.cgi?id=311623
http://blog.fubar.dk/?p=63

A solution for that will benefit more than just g-p-m.

Thanks,
Jon
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]