Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2005:
[Freeciv-Dev] Re: (PR#11851) Hack request should verify userid in additi

[Freeciv-Dev] Re: (PR#11851) Hack request should verify userid in additi

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: edoverton@xxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#11851) Hack request should verify userid in addition to random string
From: "Vasco Alexandre da Silva Costa" <vasc@xxxxxxxxxxxxxx>
Date: Mon, 10 Jan 2005 19:09:20 -0800
Reply-to: bugs@xxxxxxxxxxx

<URL: >

On Sun, 9 Jan 2005, Ed Overton wrote:

> <URL: >
> I just re-read my last update, and it comes across somewhat snippy.
> Sorry, that wasn't my intent.

That is allright. We all have our good and bad moments. :-)

> Some thoughts...
> Even with improvements, using the filesystem for userid validation still
> could have the exposure discussed earlier.  If the server were able to
> identify a file location that's solely writable by the given userid,
> there is a timespan between that determination and the client's creation
> of the challenge file.  In that timespan, a separate process might open
> up the permissions.

Assuming they can create a directory and a file at that place, which isn't
totally granted.

> I thought through some mechanisms for additional validation, and came to
> the question:  What's the goal of the hack control elevation?  It seems
> there could be two goals.  First (A), it could be aimed at managing the
> server when the server is invoked from the client.  Second (B), it could
> be aimed at elevating control for any client invoked by the same userid
> from the same machine.

The original idea was A, although a more generic mechanism that would
enable remote civserver control would also be interesting, for remote
server administration.

> In case A or in case B, the server could have a command line option that
> would enable the hack elevation.  Without the option, no hack elevation
> would be granted.  Server invocations from the client would need to
> enable the option.

Indeed. We also considered this. Our remaining question is if these
arguments will show up in the process list information via UNIX "ps" or

Mind you, the idea of saving settings at the user "Application Data"
directory is still interesting, because it will have a per user
savedgame directory and per-user client settings, etc. So I still think
that should be done, even if we change the authentication protocol.

> In case A, the hack elevation could be limited to a single client.  I
> would think it would be rare for a different client to connect before
> the original client.
> In case A, an environment variable could be used to indicate whether the
> server was invoked from the given client.  The client, prior to invoking
> the server, would create a random string.  The client would encrypt that
> string and store the encrypted version in an environment variable.  The
> client would invoke the server.  The hack elevation request would
> include the unencrypted version of the string, and the server would then
> encrypt that and compare the value to the one from the environment variable.

The environment variable option seems *very* interesting and we didn't
remember of that before IIRC. It would be worthwhile to pursue that.

> If any of those seem worthwhile, I'll be happy to have a crack at them.

The environment variable idea sounds good.

Just use the current code for generating the key. Don't worry about
encryption for now. Currently Freeciv doesn't use encryption for anything,
even when the client sends a user password, so...

Vasco Alexandre da Silva Costa @ Instituto Superior Tecnico, Lisboa

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