Bad configure check

Bad configure check

[Andreas Schwab]

This configure check is bad:

  AC_MSG_CHECKING([for access to game group "$gameuser"])
  rm -f conf$$chown.file
  touch conf$$chown.file
  dnl If we can't chown a file to group games, then the users
  dnl can't share scores.
  if chown "$gameuser" conf$$chown.file 1>/dev/null 2>&1; then
    AC_MSG_RESULT([yes])
    if test "$gamedir" = "yes"; then
      gamedir="${localstatedir}/games/emacs"
    fi
    eval tgamedir=\"$gamedir\"
    AC_DEFINE_UNQUOTED(HAVE_SHARED_GAME_DIR, "$tgamedir",
    		       [Define to the name of the shared game directory.])
  else
    AC_MSG_RESULT([no])
    gamedir=no
  fi

The ability to do chown depends on the environment, this cannot be checked
at configure time.  The user who runs configure is usually different to
the user who runs Emacs.  The test must be performed at runtime.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Bad configure check

[Colin Walters]

On Thu, 2002-04-25 at 10:19, Andreas Schwab wrote:
> This configure check is bad:

I don't see why.

[...]

> The ability to do chown depends on the environment, this cannot be checked
> at configure time.  The user who runs configure is usually different to
> the user who runs Emacs.  The test must be performed at runtime.

The test is performed to see if we can install `update-game-score' as
setuid to a specific game user. If we can't, then we don't make it
setuid, and just default to putting game scores in each users' home
directory.

How do you propose to perform this at runtime?  It don't think that
makes sense.

Re: Bad configure check

[Andreas Schwab]

Colin Walters <walters@debian.org> writes:

|> On Thu, 2002-04-25 at 10:19, Andreas Schwab wrote:
|> > This configure check is bad:
|> 
|> I don't see why.
|> 
|> [...]
|> 
|> > The ability to do chown depends on the environment, this cannot be checked
|> > at configure time.  The user who runs configure is usually different to
|> > the user who runs Emacs.  The test must be performed at runtime.
|> 
|> The test is performed to see if we can install `update-game-score' as
|> setuid to a specific game user. If we can't, then we don't make it
|> setuid, and just default to putting game scores in each users' home
|> directory.

Ok, I have misunderstood the purpose of this configure check.  But then,
it is still wrong, because the user that runs configure can still be (and
often is) different to the user that runs "make install".  This check
should be done at install time.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Bad configure check

[Richard Stallman]

    The test is performed to see if we can install `update-game-score' as
    setuid to a specific game user. If we can't, then we don't make it
    setuid, and just default to putting game scores in each users' home
    directory.

You could always use try using chown when installing
update-game-score.  If it fails, don't make it setuid.

When a game runs, it can check at run-time whether the program is
setuid, and act accordingly.

No need now to check anything in configure.

Re: Bad configure check

[Colin Walters]

On Fri, 2002-04-26 at 13:38, Richard Stallman wrote:

> You could always use try using chown when installing
> update-game-score.  If it fails, don't make it setuid.
> 
> When a game runs, it can check at run-time whether the program is
> setuid, and act accordingly.

The tricky thing about this is that update-game-score.c gets compiled
with different options depending on whether or not we have access to a
shared game directory.

If update-game-score is setuid, it must always store scores in the
shared game directory; anything else would be a security problem.  If
it's not setuid, then we store scores in the user's home directory.

Hmmm.  I suppose we can solve this problem by making update-game-score
itself check whether it's setuid, and then do the right thing
accordingly...I will investigate doing this.

Re: Bad configure check

[Colin Walters]

On Fri, 2002-04-26 at 15:28, Colin Walters wrote:

> Hmmm.  I suppose we can solve this problem by making update-game-score
> itself check whether it's setuid, and then do the right thing
> accordingly...I will investigate doing this.

Can anyone suggest a portable way to determine whether or not a program
is setuid while it's running?  My original thought was to compare the
return values of getuid() and geteuid(), but it seems this will fail if
root runs Emacs.

Re: Bad configure check

[Andreas Schwab]

Colin Walters <walters@verbum.org> writes:

|> Can anyone suggest a portable way to determine whether or not a program
|> is setuid while it's running?  My original thought was to compare the
|> return values of getuid() and geteuid(), but it seems this will fail if
|> root runs Emacs.

Does it?  Even root should obey setuid to a different user.  And
experiments show that this is the case.

# ls -l /tmp/id
-rwsr-sr-x    1 games    game       107165 Apr 15 17:28 /tmp/id
# /tmp/id
uid=0(root) gid=0(root) euid=12(games) egid=40(game) groups=0(root),1(bin),14(uucp),15(shadow),16(dialout),17(audio),65534(nogroup),65533(nobody),52(dbmaker)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Bad configure check

[Colin Walters]

On Fri, 2002-04-26 at 17:07, Andreas Schwab wrote:
> Colin Walters <walters@verbum.org> writes:
> 
> |> Can anyone suggest a portable way to determine whether or not a program
> |> is setuid while it's running?  My original thought was to compare the
> |> return values of getuid() and geteuid(), but it seems this will fail if
> |> root runs Emacs.
> 
> Does it?  Even root should obey setuid to a different user.  And
> experiments show that this is the case.

Ok, I agree with you.  I will commit changes shortly which fix the
problem.  It turns out these changes make the code cleaner, which makes
me happy.

Thanks for reporting the problem.

Re: Bad configure check

[Richard Stallman]

    The tricky thing about this is that update-game-score.c gets compiled
    with different options depending on whether or not we have access to a
    shared game directory.

It should be able to check that at run time instead.
That would be much better.

Always use a run-time check rather than a compile-time check, whenever that
is possible.

You should be able to make it stat its own executable and see if it is setuid.