[Freeciv-Dev] Re: Suggestion: libcivserver

[Paul Zastoupil <paulz@xxxxxxxx>]

Daniel Burrows wrote:
> 
> On Wed, Feb 23, 2000 at 06:22:49PM -0800, paulz@xxxxxxxxxxxxxx was heard to 
> say:
> > On Wed, Feb 23, 2000 at 08:03:30PM -0500, Daniel Burrows wrote:
> > <snip a bunch of interesting thoughts>
> > >   One other thought (I have too many thoughts :) ) -- is it possible that
> > > civserver could use a more secure method to handle certain connections, in
> > > particular privileged connections from the person who started the server 
> > > (so
> > > that random people off the 'net can't connect to the server as you if your
> > > frontend dies)  I'm wondering in particular if creating a socket in the 
> > > UNIX
> > > filesystem domain, in a 0700 directory (~/.freeciv/sockets?), and 
> > > requiring
> > > that particular player to reconnect on the secure socket would be 
> > > sufficient;
> > > as I understand things, this should be kept secure by filesystem 
> > > permissions
> > > (as secure as the filesystem is anyway, and if you lose that you're in
> > > deeper trouble than civserver can get you into :) )
> >
> > What we really need here is a client identification.  We have talked about
> > this before but as you can see no code has backed it up.  (I am formost
> > to blame, I have championed this and produced no code.)  The person
> > "controling" the civserver should not need to have a login on the machine
> > where it is running.  Lets not limit ourselves.  If we could generate a
> > key and store that in the .freecivrc file for the client it could then
> > be used to identify the client.
> 
>   I agree this is a good idea.  In fact, I posted code to this list to do a
> rather braindead :) form of identification (a year ago or so, so it's unlikely
> it'll still compile, and I lost the diff anyway..)  However, for full control
> of the civserver I *want* to be able to require the person connecting to it
> to have an account on my machine; in fact, I want to be able to require them
> to be me.  Consider that (eg) the save command could overwrite an arbitrary
> file on the system..you probably couldn't make it into an exploit, but you
> could seriously screw up my user account, destroy my data, etc.. (or we could
> just disallow the save command from a remote connection, but I think there
> should always be a 'really high' level of control for a connection that allows
> everything)

Well I understand your concern about someone controlling the server from
outside that machine, but this is as you said above this should be
function of file system permissions.  This should be something we could
turn on and off at the server level, but I don't see any problem giving
full control to a network connection, just run the server as an
unprivileged process.

> 
>   I should have been clearer there -- I think that there should be a secure
> AF_UNIX socket created /in addition/ to the standard AF_INET socket, and that
> it should be possible to restrict certain players (or for certain players to
> restrict themselves) to connecting via that socket.

The only advantage I see here is speed.

> 
> > Down the road we could allow people to register their client id and use
> > that for a ranking system, but one step at a time :)
> 
>   Nifty idea; security is an issue, though (with both forms of id, really, but
> especially with this one; other people pretending to be me and sabotaging my
> ranking is not something I want :) ).  Would some sort of public-key system
> work, or are laws (ours and other countries) still too backwards to allow
> it?

Well yes, security is an issue.  I think a key system is the way to go,
I was thinking along the lines of the way ssh works.

-- 
Paul Zastoupil