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

[Brian Cameron <Brian Cameron Sun COM>]

George:

It's great to hear from you - it's been a few years, I think, since we
have last talked about GDM.  It's good to hear your thoughts and
opinions as we are making some big decisions in relation to GDM.

> My opinion would be the following.  D-Bus is great, but if I were still doing
> the work, I doubt I would use it for the internal communication.  Internal
> chatter between slaves, master, greeters has no need to be "standard" in any
> sort of way.  It needs to just be as simple as possible to avoid security
> problems.

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.

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.

> Plus I have grown to be supporter of the thesis that upgrades should not
> break previously working configurations, and should not decrease the feature
> set if this feature set is in wide use.  The user doesn't care about internal
> organization of the code.  Rewriting a piece of code using the current "in
> vogue" model is generally pointless in my opinion and usually just pisses of
> the users.  The new version might have all the new buzzwords in it's design,
> but doesn't do half the stuff they are used to.  Think of people running
> large labs who have custom gdm configurations.  They really won't be too
> happy about having to change config and retest all their config and possibly
> run older versions of gdm if the new setup doesn't work, just because the new
> version was rewritten and only half the old feature set is working.

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.

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

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.

> Finally there is the question of security.  Rewriting large parts of the core
> should require a security audit!  Security issues tend to be subtle and
> obscure, and tend to be harder to find in more complicaled code (i.e.
> dbus/gobject/etc...)  I did not on purpose change the design to GObjects when
> I took over gdm.  Martin's design was essentially sound, so I stuck with it.
>  If you rewrite large parts of the core, be prepared for several new security
> issues to pop up soon.  (plus you really should have someone do a thorough
> security audit on new code)  Remember this code runs as "root" and can do
> VERY evil things.  Undiscovered security holes are just as bad as discovered
> ones.

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.

> One gotcha that I can think of from the top of my head, is more trouble with
> signals in the new setup.  Note that the slave is synchroneous and must
> communicate with signals.  Unless you fix this synchroneity (which is very
> subtle, you must catch ALL instances where the process could possibly hang
> and split of a new process or thread) more complicated code is more likely to
> get into subtle race conditions with signals.
>
> Do worry about race conditions coming up.

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.

> > For the time being, plans are to drop support for gdmgreeter and
> > possibly gdmsetup, though I would imagine they will be added back
> > if someone has enough interest and love to port them to the new
> > frameworks.  There is one fellow named Lukasz, who has suggested he
> > might port gdmsetup, but I'm not sure how serious he is yet.
>
> Since most distros/users use gdmgreeter shouldn't lack of gdmgreeter be
> considered a big regression?

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.

That said, most distros have already informed me that they want the
new D-Bus features even if it means gdmgreeter goes away.

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

> > George, another thing I wanted to mention to you is that William
> > believes that he was rewritten (almost) all the code that existed
> > before I became maintainer.  There are a few small bits of older
> > code still lying around.  William and other involved people have
> > expressed they want to drop the Queen of England as maintainer and
> > copyright owner.  George, I believe it was you who added the Queen as
> > maintainer and copyright holder.  Is that right?
>
> If he wants to actually and truly rewrite all the code just because the
> copyright holder is queen of england, I would have him (and others who hold
> this opinion) to check with a psychiatrist.  Queen of England was given the
> maintainership precisely to piss off ego centric people who want to put their
> name up on a pedestal.  It was also to piss off anyone who was unreasonably
> serious.
>
> Anyway, the copyright cannot be legally held by queen of england anyway, and
> is held by me if you really want to purge her name from there.  Since I don't
> work on gdm anymore I don't care what you guys do with her.  Although I don't
> see any harm in having Queen of England in the list of copyright holders
> instead of me.  But feel free to purge her name, and really don't rewrite
> things for such a stupid reason.

I don't think a real decision has been made about this yet.  We probably
need to discuss this further and find out what consensus really thinks.
Since a copyright ownership of the "Queen of England" is meaningless and
really a pseudonym for you, perhaps we will decide (in the long run)
that we really do have a sense of humor and that retaining this isn't
such a big deal?

At any rate, I appreciate that you are being so reasonable.  It is great
to know that we have the freedom to drop the Queen as a copyright holder
if, and when, this ever becomes something we wish to do.  It's good to
know we don't have to purge any code to do this.  Thanks.

> > If so, I wanted to ask your thoughts about this.  Would you be
> > willing to drop the Queen as maintainer and copyright holder of
> > the older bits of code that you worked on?  If so, this would
> > allow the project to keep the older code and avoid current plans
> > to rewrite it.  Whatever your thoughts on the matter, it might be
> > useful if you could send an email to gdm-list gnome org and let
> > people know what you think about this.  It might also be useful
> > if you were to look over the new code and verify whether you
> > agree that the older code owned by the Queen has been removed
> > as William believes.
>
> I would actually doubt that all this code (that I did from the time I took
> over until you did) has been rewritten.  But I don't care, feel free to
> remove the queen if there is a sufficient contingent of real coders lacking
> the sense of humor.

When Jon told me this, I was likewise surprised.  Then I reviewed the
code a bit more closely.  I have to say that I couldn't identify
anything that resembled the older code (aside from in the places Jon
highlighted in daemon/main.c, daemon/auth.c, and
common/gdm-common-unknown-origin.c).  If you have a minute to look
over the code more closely and let us know if you see more old code
lying around, that would be useful to know.

Again thanks,

Brian