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

[Jiri Lebl <jirka 5z com>]

Brian Cameron wrote:
> 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.

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.

> 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 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.

> 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).

> 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.

> 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.

> 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.

>> 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.  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.

George

-- 
George <jirka 5z com>
   I wanna be sedated.  -- Ramones