Re: gtk+-1.2.10

["J. Ali Harlow" <gtk-list avrc city ac uk>]

On Wed, 14 Mar 2001, Owen Taylor wrote:
> "J. Ali Harlow" <gtk-list optosun7 city ac uk> writes:
> 
> > Good to know. Have the GTK+ team come to a view on a mechanism to override the
> > setguid check? If not, is there any chance you could so before 1.2.10 is
> > released. I'll happily log a bug if that would be appropriate.
> 
> Please repeat after me:
> 
>  By making the GTK+ application run setgid, you would make the files,
>  and all other files and directories owned by that user
>  world writeable for all practical purposes.

By making the GTK+ application run setgid, you would make the files,
and all other files and directories owned by that GROUP
world writeable for all practical purposes.

> Do you still need a mechanism other than simply making the files
> world writeable knowing that? 

Well, yes.

> With the setgid operation you had with GTK+-1.2.8, any user can change
> any of their saved games, any of the score files, and any of any
> any other user's saved games.

Sure, it would be possible. It does however create a reasonable hurdle for
would-be cheats to climb.

> With a change to the permissions, and no setgid operation, you
> would at least remove the ability change other user's saved
> games.

Granted.

> Please just fix your application. In the quick look I took GTK+
> frontend is only 7000 lines or so, with a strong separation between
> that and the core. Splitting that apart into a separate process
> is simply not that hard.

We're working on it. It's isn't quite as simple as it looks however. There's a
strong abstraction in the windowing interface API (so that calls from the game
core to the windowing interface are few, and go through a central mechanism).
There is, however, no abstraction on the callbacks (ie., windowing interfaces
currently have access to the game core's data structures and utility functions.
Many, including the gtk and gnome interfaces, take good advantage of this).

We'll get there, but it _will_ take time. I'm currently estimating that the
current Slash'EM development cycle will be six months, by the end of which I
hope to have plugable interfaces in place. In the meantime, we will be forced
to ship stable versions that subvert your check if you refuse to provide a
workaround. The code is already written and in place. The user will see
nothing. I would be delighted to delete it if 1.2.9 was the only version that
needed it.

As Ben Gertzfield points out in a seperate message this problem also affects
NetHack. I can't speak for their dev-team, but I will note that we have been
talking about this; that they have a copy of my code to subvert; and that it's
been quite a while since their last release, with a number of bugs listed as
fixed on their bug list. If they were to release a 3.3.2 version containing the
subverting code that could be around for years to come.

> Regards,
>                                         Owen
> 
> [ The only workaround that I'd even consider is an Havoc's
>   suggesting of an environment variable like:
> 
>    GTK_ENABLE_SETUGID_HAXORING
> 
>  Though it would worry me that people who don't understand
>  setugid GTK+ is equivalent to a setugid shell would try
>  to set that from their source code. ]

So don't document it. Spit out a warning message telling everybody just that.

As a final thought, do you have any concept of what packagers are likely to do?
Is it going to be like Qt, with Linux distributions shipping with 1.2.x and 2.x
versions of GTK+ for some time to come? If so, you could include a workaround
in the 1.2.x series but drop it from 2.x. This way we can continue to link
against 1.2.x, fix the real problem before 1.2.x gets dropped and then take
advantage of all the extra facilities 2.x provides.

-- 
Ali Harlow                              Email: ali avrc city ac uk
Research programmer                     Tel:   (020) 7477 8000 X 4348
Applied Vision Research Centre          Intl: +44 20 7477 8000 X 4348
City University                         Fax:   (020) 7505 5515
London                                  Intl: +44 20 7505 5515