Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

Coverity catches X Window Security Hole

Posted May 3, 2006 1:18 UTC (Wed) by davej (guest, #354)
In reply to: Coverity catches X Window Security Hole by cortana
Parent article: Coverity catches X Window Security Hole

neither -Wall or -Wextra will catch this bug.

The only thing I've found that prints any warning at all, is splint, which prints the following...

test.c:5:23: Operands of != have incompatible types ([function (void) returns
                __uid_t], int): geteuid != 0
  Types are incompatible. (Use -type to inhibit warning)

gcc is completely silent on the matter.

(Log in to post comments)

Coverity catches X Window Security Hole

Posted May 3, 2006 3:46 UTC (Wed) by jreiser (subscriber, #11027) [Link]

geteuid != 0

gcc is completely silent on the matter.

Then that's an `"opportunity for enhancement" in the compiler :-) As long gcc knows that geteuid is not a weak external [such as if there is an "unprotected" call geteuid() anywhere else in the same compilation unit], then there should be a warning that the comparison is between constants and is always true [the address of a non-weak defined subroutine is never 0.]

Deja Vu

Posted May 3, 2006 6:24 UTC (Wed) by Ross (subscriber, #4065) [Link]

Didn't we already have this discussion? This is the same hole that was announced 3-4 weeks back. My opinion is still that GCC should be warning about this usage in -Wall (really anywhere a function is being compared with any constant, unless it's weak and the constant is NULL), and that the X sources should be cleaned up enough that the warning wouldn't be lost in the noise.