fix up a few pieces of doc.

NOTE: FreeBSD has now integrated issetugid() into their system and have
changed the semantics!  Their's will return 1 if a process has called
setuid() or setgid() ---- ours was specifically designed to be decoupled
from that behaviour.

diff --git a/lib/libc/sys/issetugid.2 b/lib/libc/sys/issetugid.2
index 5d15f4e..975878f 100644 (file)
--- a/lib/libc/sys/issetugid.2
+++ b/lib/libc/sys/issetugid.2
@@ -1,4 +1,4 @@
-.\"    $OpenBSD: issetugid.2,v 1.8 1997/04/10 01:13:27 millert Exp $
+.\"    $OpenBSD: issetugid.2,v 1.9 1997/04/10 09:41:22 deraadt Exp $
 .\"
 .\" Copyright (c) 1980, 1991, 1993
 .\"    The Regents of the University of California.  All rights reserved.
@@ -50,25 +50,37 @@ the result of the last
 system call.
 Otherwise it returns 0.
 .Pp
-This system call exists so that library routines (inside libc, libtermlib,
+This system call exists so that library routines (inside libtermlib, libc,
 or other libraries) can gaurantee safe behavior when used inside
 setuid or setgid programs.
 Some library routines may not be passed sufficient information to know
 if the current program was started setuid or setgid because higher level
 calling code may have made changes to the uid or the euid.
+.Pp
 In particular, it is wise to use this call to determine if a
 pathname returned from a
 .Fn getenv
 call may safely be used to
 .Fn open
 the specified file.
+Quite often this is not wise because the status of the effective uid
+is not known.
 .Pp
+The 
 .Fn issetugid
-is unaffected by calls to
+system call's result is unaffected by calls to
 .Fn setuid ,
+.Fn setgid ,
+or other such calls.
+In case of a
 .Fn fork ,
-and other such calls.  It is only controlled by
-.Fn execve .
+the child process inherits the same status.
+The status of
+.Fn issetugid
+is only affected by
+.Fn execve ,
+meaning that if a child process executes a new binary a new
+status will be determined based on the executable file modes.
 .Sh ERRORS
 The
 .Fn issetugid