Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2002:
[Freeciv-Dev] Re: connect dialog ver 3 (PR#1911)
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Freeciv-Dev <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: connect dialog ver 3 (PR#1911)
From: Reinier Post <rp@xxxxxxxxxx>
Date: Wed, 23 Oct 2002 09:25:01 +0200

On Tue, Oct 22, 2002 at 09:59:25AM +0000, Per I. Mathisen wrote:

> My vision for the server to be a (possibly forked) daemon running in the
> background which (unless it is a public server) runs until there are no
> more players connected to it (or no players connect to it in a given
> timeframe). First player to connect gets control priviledges and no unsafe
> "hack" priviledges exist.

This is already implemented - you don't need hack level to run or control
a game.  You only need it for things that affect the file system, like
"save", "load", "read" or "write".

> This means changing "save" and "load" so that they cannot overwrite
> anything useful on the system. This should be relatively simple - restrict
> them to a directory of their own, and check that any files to be loaded or
> overwritten are also freeciv savefiles. Note that this change will also be
> necessary if load and save is ever to be implemented on civserver. The
> same goes for loading rulesets.

It requires more scrutiny to do this right.  A well known security hole
is to allow files to be used from publically writeable directories like
/tmp, where peopple can place symlinks.  I remember one case where the
program would verify that the file didn't exist, then write the file -
while the attacker would run a program that would create and remove a
symlink in a loop; that way the file could still end up being controlled
by the attacker.  So the directory must not be writeable by others.

> > Also pipes are not easily portable to other platforms. Unlike
> > BSD sockets UNIX pipes are not ubiquitous. Not to mention fork() ...
> 
> I agree pipes are bad. However, I don't see a fundamental problem getting
> a fork mechanism working for multiple platforms - this is already solved
> in Mike auth patch AFAIK for both unix and win32 platforms.

What is wrong with turning all commands to /set commands (e.g. /start
would be an alias for /set gamestatus running) and turning the
"server options" dialog into a bunch of editable settings?

> > You can do a GUI to control the server regardless of this nonsense.
> 
> It is my hope that eventually any UI for the server will be unnecessary,
> and that using its commandline will be an option used only for debugging.

How do you mean?  The game settings have to be determined by the users.

>   - Per

-- 
Reinier


[Prev in Thread] Current Thread [Next in Thread]