[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Non-compliant access behavior?

From: J de Boyne Pollard
Subject: Re: Non-compliant access behavior?
Date: Thu, 24 Dec 2009 09:51:01 -0800 (PST)
User-agent: G2/1.0

ST> That's why I put a question mark in the subject.

And that's why you were told the answer.

ST> The problem I encountered is that I couldn't run gcc over
ST> files in a directory which belonged to a group my I was in.
ST> I hope you'll too find it quite surprising.  

Only inasmuch as gcc is even using access(), whose use is only really
appropriate in the context of set-UID or set-GID executables, and even
then is a security hole generation tool. Since when was your compiler

ST> Be it POSIX-compliancy or not, I believe following
ST> what gcc thinks is compliant would be useful.

Then you're wrong.  It wouldn't be useful. access() isn't useful.
It's a bad idea whose use should be avoided.  (If you want to find out
why, read the Bugtraq archives from 1994 for starters.  Yes, this
system call's problems have been known about for at least 15 years.)
If gcc is using it, which I'm simply taking your word for, then that's
a problem in gcc that needs to be looked at, with one's security-
conscious head on.  If gcc's abuse of it doesn't actually work on some
systems, then that's *still* a problem in gcc that needs to be looked

The standard itself explicitly says that supplementary group IDs and
their relationship to effective group ID is unspecified, and even if
using access() *were not* a potential security problem in gcc that
needs careful review, resulting from an issue that has been known to
be problematic for 15 years, gcc would still be relying upon non-
portable implementation-specific behaviour of a system call.

reply via email to

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