Bug#717912: libc0.1: getauxval() nonfunctional on kfreebsd

[Petr Salinger <Petr.Salinger@seznam.cz>]

> That means: AT_UID/et.al. are defined in the header, the kernel knows
> about them, but they are not usable though getauxval().

Not exactly. These are defined, kernel does not supply them at all.
Which is perfectly valid behaviour.

> That is where the actual bug is,
> i.e. the headers are at odds with the kernel?

Yes, it is a header bug. It should not define AT_SECURE to
value with different meaning.

> > What is your use case for getauxval() ?

> p11-kit 0.18.5 uses getauxval (AT_SECURE) to detect SUID or SGID 
> execution.

> It checks at configure time for the function with
> AC_CHECK_FUNCS([getauxval], but not whether AT_SECURE works. If
> getauxval is missing a replacement will be used. The fact that
> getauxval(AT_SECURE) does not throw a compiler error on freebsd (as
> in: error: 'AT_SECURE' undeclared) makes writing a configure test
> unnecessarily complicated.

Blindly using getauxval() for detecting issetugid () is wrong approach,
especially for security detection.

Please see man page:

RETURN VALUE
       On success, getauxval() returns the value corresponding to type. 
If type is not found, 0 is returned.

ERRORS
       No errors are diagnosed.

There is no guarantee, that when AT_SECURE is defined,
it will be also supplied by kernel.

Similarly for other AT_* even under Linux.
Compare elf.h header under Linux and
  LD_SHOW_AUXV=1 /bin/true

Petr