We consider if setuid can solve the Confused Deputy’s problem. I think that it can solve the narrow problem but not obvious extensions of the problem.

I have tried to learn from the man pages in Solaris, BSD, and Linux, about what user IDs can be set by a program. They seem to describe mostly the same thing in different words. Some give more details. But the confused deputy is not about a program mis-using authority it should not have. We are trying to design a program that must run with more authority than its invoker, and will not abuse that extra authority. In that regard the Unix setuid function is for the program to distinguish between two sources of authority.

The confused deputy was originally designed to use only the invoker’s authority. When it evolved to require write access beyond that of the invoker it had to distinguish between its authority sources.

It seems that the compiler should, upon invocation, initially assume the invoker’s authority while retaining, in the “saved user ID”, the ability to resume the compiler’s authority when it is time to write the feature usage report.

In summary setuid and its friends indicate a recognition of problems such as the confused deputy but restrict the solution to just one other source. Also setuid seems incompatible with threads. The uid that is set applies to the process and thus all threads. Perhaps there is a scheme to guard all authority sensitive code with semaphores but this may interfere with the purpose of threads.

It is my experience with capability systems that these problems do not arise in the first place and that the natural way to code such applications is immune to this sort of problem.