seteuid() from root to "temporarily" run as a non-privileged user would be OK if it were only ever used to truly _temporarily_ run to access user-owned files safely as the user. However this is folly and unnecessary as it can be done more safely with fork()+setuid(), more safely and transparently with fopen_as(), or more safely and more efficiently with a new system call: open_as(), plus fopen_as() wrapper. However naive programmers often assume it is useful to drop privileges to some user such as "nobody" when running a setUID program and then to only return to privilege temporarily when this is necessary to perform some privilege-requiring operation. Unfortunately this latter use of seteuid() is usually of no benefit whatsoever, especially against any foreign code execution attacks such as those afforded by buffer-overflow bugs and the like in network daemons. The problem is that the foreign code can just as easily call seteuid(0) to regain privilege for itself. A prefect example of a real exploit made possible by such naive abuse of temporary EUID-ness for seteuid(0) was in the Solaris 2.6 "ufsdump" exploit: https://seclists.org/bugtraq/1998/Apr/144a https://seclists.org/bugtraq/1998/Dec/217 Note also in this paper Tim Brown suggests that a dynamically linked setUID program can "fool" ld.so into trusting LD_PRELOAD, etc. http://www.nth-dimension.org.uk/downloads.php?id=77