GNOME.org
 

Re: [gdm-list] George & Martin - update about GDM


George:


I disagree.  Over the years we have had a number of security issues
caused because of dumb errors in how GDM manages its own communication
mechanism.  For example, recently someone figured out how to cause the
daemon to core-dump with a carefully crafted message, causing a
denial-of-service issue.  By using D-Bus, we should avoid having such
problems.


There is still a problem of how gdm uses the information.  I.e.  D-Bus will
not solve such denial of service problems.  Anyway, I was talking about the
internal pipe which is root writable only.  I would use dbus I suppose
instead of the user writable socket.  I can see some benefit there.  There's
also how greeters communicate with the daemon where there is also not much
need for dbus.


> Doing internal communication through a channel that allows user
> connections requires authentication and that always allows the
> possibility of problems.

Jon can correct me if I get some of these details wrong.

The stdin/stdout pipe which used to pass back and forth PAM stuff like
username/password has been changed to use a private D-Bus communication
channel.  The GDM daemon acts as its own D-Bus server and only allows
the GUI's to connect for such communication.

A public D-Bus communications channel is used for "gdmflexiserver
--command" style interactions.  So normal users will be able to continue
to control GDM and get information from GDM as they can today.

So, some protections are in place in the new code to ensure that
sensitive information can't be exploited.  Perhaps Jon could elaborate
since I don't think the new security model is explained much in the
existing documentation.  Since this is a pretty significant change in
how sensitive data is passed around, there should be more discussion
about how we are planning to manage keeping things secure.

The username/password information is not sent on a channel that allows
user connections, except to the gdm user running the GUI clients.


There is suddenly a LOT of code that touches the internal chatter where there
need be very little.


Having said that, I do think that we need to carefully consider the
security implications of how we use D-Bus in GDM.  It would be good
if there were more documentation about how the changes to use D-Bus
affects security in GDM, I think.


This needs to be well thought out, not just implemented.  with a more
complicated mechanism, the security implications can become rather subtle.
And while dbus may be secure (though note that's another assumption you are
piling on), how dbus is being used must be carefully thought out.


Yes, which is why the new security model should be better documented, so
that more people can review and we can ensure that people feel the new
model is reasonable.


As maintainer, I know I have been responsible for a few things that you
warned me not to do for this reason, including moving many binaries
away from /usr/bin and into /usr/lib and /usr/sbin.  Also with the
rewrite of the configuration system so it uses the current
default/custom split.  Although some users were indeed pissed off, I
don't think the reactions were as bad as you warned.  In fact, most
reactions were positive once we got past the initial annoyances.


Well you are the maintainer and so it is your call.  I know I am very
conservative when it comes to this point.  I would urge you though to really
think this through so that you can keep with the new setup unchanged for say
the next decade.


I think this is a good thing to strive for.


I believe our intention is not to drop any features that users
really care about.  It is our belief that many configuration features
are not really used and only make maintaining GDM difficult.  Therefore,
we plan to "piss off" our users in a carefully managed way.  :)


Yeah some things in the config are useless, however there are many very
strange gdm setups being used.  Not on home desktops, but in computer labs,
thin clients, etc...  So the userbase for those is small, but important I think.


I agree.  I think we should continue to make efforts to support users
who have special configurations, within reason.


Our plan is to plug in all those configuration options that we think
make sense and drop the rest in the next unstable release.  Then, we
will see who complains to get a better feeling for what other features
are really considered important by our userbase.  If arguments are
compelling, then we will (of course) plug back in needed features.


You will not see most of these sysadmins running unstable releases.  Judging
from say the setup at UIUC, the current setup will probably be used for say
3-5 years now without much change.  These are not people who like to upgrade.
 They will also likely not complain, they will either run old GDM or
something else, which is usually not the best situation for gnome (or the users).


Yes, this is a risk.  Especially if we end up doing a poor job of
supporting the needs of our users, especially ones with unique setups.


Your point that the new code really should be audited is a good one.
Though this should probably wait until we get the code a bit more
finished.


Well, to a degree.  To use a chess metaphor, think strategy vs. tactics.  You
want to audit your strategy at this point.


This public discussion, while probably not a formal audit, does create
an opportunity for people to get involved with reviewing the code and
making sure that the strategy is sound.


Yes, these are areas that still cause problems in the stable GDM.  I
know that Sun Ray users, for example, still hit weird situations where
GDM will stop managing a specific display for no clear reason.


This is very hard to solve.  The synchronous setup is probably best in this
situation since it is much easier to follow the code.  In an event based code
you'd have a much harder time following the chain of events.  Also for truly
asynch slave you must make all the operations it does asynch.  This requires
for example rewriting the parts of Xlib that are needed to be asynch.


Most of the problems seem to be in how the signal handling is done and
with problems with the longjmp stuff.  The new D-Bus GDM, with its use
of gobjects and better main loop integration should improve things here.


I think we will see.  If someone considers this a big enough regression
to help port gdmgreeter to use the new interfaces, then I am sure it
can be added back.


This is fine attitude, but unfortunately it doesn't quite work as I have
found out.  There are many a free software that went into rewrite and sucked
badly and while widely used no one helped to fix regressions.  Best example I
can think of the top of my head is gphoto.  Or think eye of gnome.  Everybody
complained for years that it is unusable as an image viewer, but nobody fixed
it.  It only recently became actually usable for anything other than viewing
a single image.

That is, you may make GDM very unpopular and drive people towards other
solutions without getting any help.


I hope that we avoid this, but there is a risk that the next release of
GDM will be a bit of a regression.  There are several active GDM
developers at the moment, so my hope is that we will keep things under
reasonable control.


As for gdm setup, you mean there won't even be a way to support a gui
configuration?  That does sound like a BIG regression for gnome.

If gdmsetup worked properly, then I'd agree with you more.  :)  The
fact that you must run it as root is a big problem in terms of security
and accessibility.  It probably needs significant overhaul to address
these problems anyway.  I believe Lukasz is interested in addressing
these problems along with the work he plans to do.  He already has
a patch which fixes gdmsetup so it has an "Apply" button and makes
configuration changes when this button is pressed rather than as-you-go,
which makes fixing the "need to run as root" issue more simple to
address, for example.


Well, it is still a regression.  I suppose it is not ideal, but actually I am
running on ubuntu and gdmsetup runs exactly just like all the other config
programs that modify the system.  I'm actually not too crazy about the
gdmsetup of nowdays as I think there are some options which are crack.


Please file bugs if you have suggestions on how to improve things.  :)
I think your opinions are always valued, even though I am perhaps not
quite as conservative as you on some of these points.


But
there are things that a user may want to change.  For example by taking away
gdmsetup you have for all practical purposes removed automatic login and
timed login features, since people won't use them if they can't run a gui
setup.  So it will be a regression even if it is not a regression in a
technical sense.

>

My feeling on this would be that you shouldn't replace a piece of software
with a new one until the new one is complete.

The idea that if something is not 100% perfect then it need not be there
(i.e. gdmsetup has flaws hence it need not be there at all) is bogus I think,
and it is something that made lots of early gnome suck badly.  There was lots
of places where we were waiting for god to give us the perfect piece of code
to solve a certain problem and in the meantime there was either no way of
doing a certain task or it sucked very badly.  In the meantime there were
"good enough" choices out there, but they were ignored because they didn't
conform to the current standard of perfection.

Beware of that.  You will never solve anything in a perfect way.  And if you
wait until it is done in a perfect way, then it will never happen and the
software will generally suck donkeyballs.


Thanks - I really do appreciate the feedback.  I think your concerns are
worth hearing as we push forward for 2.21.  My hope is that your words
encourage all of us to strive to make the transition to using D-Bus as
smooth as possible so that nobody thinks GDM sucks donkeyballs.  :)

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