SUMMARY: How To Write a SETUID Program

From: joel.d.spieth (
Date: Mon Mar 10 1997 - 13:30:41 CST

Thanks to everyone who replied.

I received a couple of reminders that this is not a programming forum.
However, since system administration often involves programming in order to
automate mundane tasks, I thought that this forum would have been acceptable.
I will refrain from programming posts in the future. I am sorry for any

Since I am already wasting network resources with this apology, here is the
summary. I haven't had time to verify the web sites yet, so happy hunting.

AROSSITE @ ("Bruce Rossiter")
jstanley @
mhkohne @ (Michael Kohne)
benites @ (Robert Benites)
tel1dvw @ (dave)
vogelke @ ("Karl E. Vogel")
cyucel @ (Cagri Yucel)
jefi @ (Jens Fischer)
peter.allan @ (Peter M Allan)

1. The article I was looking for by Bishop was in the USENIX newsletter in
Bishop, Matt. "How to Write a Setuid Program." ;login: 12, 1 (Jan/Feb
1987): 5-12.
2. Check out the Chapter in Practical Unix and Internet Security by O'Reilly
3. Good info in Advanced Unix Programming by the TCP/IP and Unix Net
Programming Guru Richard Stevens
4. More info at
5. More info at
6. More info at

7. Friendly advice from a contributor

Don't read random-sized input into a fixed size buffer. Always make sure
your reads will truncate the input, preventing buffer over-runs.

This means you shouldn't use any C library function which might have an
internal buffer, or which uses a user-supplied buffer without havin anyway
to know how big it is. 'gets' is especially vulnerable, as are several
other functions. Basically, you need to think about each library function
and say to yourself 'If I had to implement that, might I do with a static
buffer of some sort?' If the answer is yes, don't use it.

My other piece of advise is to keep the setuid part of the program down to
a minimum. The setuid portion of things is the one the crackers are after,
and the more complex it is, the more likely it is them will find a way to
compromise it, despite your best efforts. If you can arrange things so that
most of the actual processing is done at a lower effective UID, so much the
better. (Of course, proper management of any UID switches within the
program is needed).

8. See the Man Page from COPS on setuid

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:48 CDT