Re: Non-compliant access behavior?

[J de Boyne Pollard]

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
set-UID/set-GID?

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
at.

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.