[bf1942] Linux server status report: 2003-03-31

Fredriksson, Andreas andreas.fredriksson at dice.se
Tue Apr 1 04:35:42 EST 2003


It would be a local exploit though, since the server ports are not
bound until the engine is fully loaded and configured; but I agree
this isn't exactly good either. 

Andreas

-----Original Message-----
From: Daniel Valois
To: bf1942 at icculus.org
Sent: 4/1/2003 11:34 AM
Subject: RE: [bf1942] Linux server status report: 2003-03-31

That sounds like a vulnerability waiting to happen

-----Original Message-----
From: Fredriksson, Andreas [mailto:andreas.fredriksson at dice.se] 
Sent: Tuesday, April 01, 2003 3:29 AM
To: 'bf1942 at icculus.org '
Subject: RE: [bf1942] Linux server status report: 2003-03-31

 
Paul,

the loading code is completely linear so it would be very
hard to make it release the CPU now and then.

Also, once you increase the process niceness (via setpriority(2)),
you cannot lower it again due to unix custom--except if you're root..

And no, we don't want the server to run as root! :-)
Perhaps a suid/nice+load+unnice+droppriv combo could be developed, but
I think it's low priority for the time being.

Our first goal has to be to release a server of acceptable quality,
features will have to wait.

Regards,
Andreas

-----Original Message-----
From: Paul Richards
To: bf1942 at icculus.org
Sent: 4/1/2003 10:45 AM
Subject: Re: [bf1942] Linux server status report: 2003-03-31

Is it not possible to add a switch or setting where we can choose the
maximum cpu usage that the server can use on a map change? Or just have
a
switch that makes the server use only say 50% of the CPU on a map
change, at
least then we have the choice of whether our servers run slower during a
map
change... Or it automatically goes to a lower priority and therefore
doesnt
effect other processes running....

This is probably a tall order, but alot of people will need to run more
than
one BF server on a single CPU system, I would think a solution is
definitly
needed.

----- Original Message -----
From: "Fredriksson, Andreas" <andreas.fredriksson at dice.se>
To: <bf1942 at icculus.org>
Sent: Tuesday, April 01, 2003 8:23 AM
Subject: RE: [bf1942] Linux server status report: 2003-03-31


>
> Andrew,
>
> the CPU load comes from all the disk I/O and file parsing going on
> at level load time.
>
> There's not much to do about this except maybe providing callbacks to
> some external root-uid process that can change the niceness of the
> main bf1942 thread during loading. But that way clients will have to
> wait longer before they can connect to the new map, so it's not
> a perfect solution either.
>
> Regards,
> Andreas
>
> -----Original Message-----
> From: Andrew Chen
> To: bf1942 at icculus.org
> Sent: 3/31/2003 8:21 PM
> Subject: Re: [bf1942] Linux server status report: 2003-03-31
>
> At 05:20 AM 3/31/2003, you wrote:
> >- The Linux server is compiled with gcc3 now, and this has uncovered
> >   some pretty nasty bugs that were masked out by gcc2/msvc. I'm
still
> >   sorting out library issues and how we are going to distribute the
> >   package. Would a completely static version be acceptable for
people
> >   with older distributions?
>
> Hehe, I called it, didn't I?  :)
>
> How about a static version and a dynamic version?  That way we can
> choose
> which one we want to run.  The solution should NOT be maintaining both
a
>
> gcc2 and gcc3 build, though.
>
> In other news...
> Is it possible to make the server NOT obliterate the CPU on
> mapchange/daemon restart?  This applied in win32 as well.  On restart,
> it
> pretty much sucks up all available CPU time, meaning that you can only
> run
> 1 BF server on a single CPU system.
>
>





More information about the Bf1942 mailing list