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

[Freeciv-Dev] (PR#11851) Hack request should verify userid in addition t

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Subject: [Freeciv-Dev] (PR#11851) Hack request should verify userid in addition to random string
From: "Ed Overton" <edoverton@xxxxxxxxxx>
Date: Sun, 9 Jan 2005 17:53:09 -0800
Reply-to: bugs@xxxxxxxxxxx

<URL: http://bugs.freeciv.org/Ticket/Display.html?id=11851 >

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

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.

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.

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.

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.

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

Ed



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