[Freeciv-Dev] Re: connect dialog ver 3 (PR#1911)

["Per I. Mathisen" <per@xxxxxxxxxxx>]

On Wed, 23 Oct 2002, Mike Kaufman wrote:
> > Say Freeciv creates ~/.freeciv/savegames/ with chmod 700. I don't see any
> > way a hostile local user or a network user may manage to exploit it with
> > the restrictions mentioned above.
>
> no. this is crazy.An attacker can simply fill up your hard drive with
> savegames.

We can set a limit on how many savegames that can be created. We can have
X savegame "slots" for each game, identified by an increasing game number,
say in ~/.freeciv/games/$number/. There are other possibilities.

This is a problem that can be solved with a good design.

> It's clear to me now that if we're going to do this, we're going to have to
> do it right and that means public key encryption.

This is probably necessary for player authentication anyway, but I still
think it is no excuse for solving a design problem by merely adding more
code.

Note how your solution does not solve the case of saving and loading games
on public servers such as civserver.

> I think vasc is right: it's certainly easier to send commands to the
> server via sockets rather than pipes.

Agreed.

> All it requires is making sure the server knows who it's
> talking too. A key or password written to a file that both the server and
> client running with the same uid have access to is an easy way to
> accomplish that.

I am not convinced (yet) that this is necessary.

> I propose:
>
> o a cut down RSA encrypt/decrypt module in common/ (useful in client
> authentication too.)
> o a new packet pair for doing the said cypto handshakes, etc
> o a new packet pair for sending commands to the server and success/fail
> replies. (maybe)
> o a small routine to generate a passfile so that the client is authorized
> to send hack commands to the server.
> o a server commandline option to direct it to generate the passfile is a
> certain location. (or to act like a spawned server or whatever)
>
> In this case, we can avoid fork() and pipe().

I still want fork(), though.

  - Per