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. > 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). > 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. > 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. > > 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). > 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. 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). This is really the crux of the argument and honestly I'm not in a position to really comment on if it's true or not since I've not been around on the Gnome scene for very long. Cheers.
Attachment:
signature.asc
Description: This is a digitally signed message part