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.
