Complete.Org: Mailing Lists: Archives: freeciv-dev: July 1999:
Re: [Freeciv-Dev] Another OS/2 issue

Re: [Freeciv-Dev] Another OS/2 issue

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Alexander Mai <st002279@xxxxxxxxxxxxxxxxxxxxxx>, "freeciv-dev@xxxxxxxxxxx" <freeciv-dev@xxxxxxxxxxx>
Subject: Re: [Freeciv-Dev] Another OS/2 issue
From: Daniel Burrows <Daniel_Burrows@xxxxxxxxx>
Date: Tue, 27 Jul 1999 07:39:15 -0400

On Mon, Jul 26, 1999 at 11:04:07PM -0400, Greg Wooledge was heard to say:
> Alexander Mai (st002279@xxxxxxxxxxxxxxxxxxxxxx) wrote:
> > First an addition to the sys/select.h stuff:
> > 
> > given the configure patch one may adjust the lines in
> > sernet.c, civserver.c and mapview.c, too.
> > It seems to affect AIX, too. Another fine IBM product ;-)
> I've been running the civserver on AIX (4.3.2) without any problems.
> > +#ifndef __EMX__
> >    if (!getuid() || !geteuid()) {
> >      fprintf(stderr, "%s: Fatal error: you're trying to run me as 
> > superuser!\n",
> >         (argv[0] ? argv[0] : "freeciv_server"));
> Embedding names of platforms and development environments is not the
> "Right Way" to do it -- it's what autoconf is designed to avoid.
> However, as I understand it, a lot of the compilers for single-user
> operating systems have getuid() and related calls for Unix compatibility,
> but these calls always return 0 (or some such behavior).  Thus, a simple
> autoconf check for getuid() will fail to detect that this platform's
> implementation is a merely a stub.
> (If you check that getuid() returns a non-zero value, then compilation
> of freeciv as root on a Unix-like box will give undesirable behavior
> in the resulting executable.  A lot of newbie Linux users compile/run
> everything as root, so ironically the exact scenario that the above code
> is trying to avoid would be aggravated.)
> Does anyone know of a good way to determine (at ./configure time) whether
> one is on a multi-user or single-user operating system?

  If the platform has setuid() as well, you could try to change uid to something
non-zero and see whether it was effective by calling getuid() again.  This
assumes that platforms with stub getuid() are going to have stub setuid() calls
and not go through elaborate trickery to convince us that we really have
changed the uid.. :)


  "I've struggled with reality for thirty-five years, but I'm glad to say that
   I finally won."
     -- _Harvey_

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