> It seems to me (and in fact I maintain a libc that does this) that
> there are a number of system calls whose result can be known to libc
> without bothering to talk to the kernel.  The obvious ones are
> getpid(), getppid(), and so forth but getgroups() ought to fall into
> this category too after the first call, and barring any use of
> certain intermediate syscalls.

getppid actually does not qualify, since the parent can die, and the
ppid thus change to 1, without libc having a chance to notice.

> This would cause problems for applications that mixed hand-coded
> syscalls and libc, but I'm not so sure I care,

Why not?  Do you have reason to think nobody is doing that?  (Not
having reason to think anybody is is not the same as having reason to
think nobody is.)

Furthermore, you don't mention any reason to think that the calls that
can be optimized this way are used heavily enough to make it worth the
bother - and potential compatability issues - of doing so.  Do you have
such a reason?  ("No" is a pefectly reasonable answer; I'm not trying
to shoot down an idea.  Doing experiments without specific needs
driving them is a sane thing to do.  But the level and kind of interest
in the results is definitely affected by the needs, if any, behind
them.)

> unless there's a security issue -- and I do not see one, though I'd
> be glad to be educated if there is.

Hmm.  It occurs to me that a user-level cache of values for
getgroups(), getuid(), etc, could be corrupted by userland.  The most
obvious case is something that allows arbitrary code execution, such as
a classic stack-smash.  While I see little point in caring about that
case, it's not that implausible that there may be bugs that could allow
an attacker to store (say) an int into an arbitrary data-segment
location, which doesn't lead to stack smashing but could corrupt a
cache like this.  However, I've been unable to come up with a case
where such a thing could lead to anything worse than what the original
bug already allows.

Hmm.  What about threads?  How does your optimization interact with
threads?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B