Xref: utzoo comp.unix.xenix:4819 comp.unix.wizards:14549
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!nrl-cmf!ukma!rutgers!njin!princeton!andante!raf
From: raf@andante.UUCP (Roger Faulkner)
Newsgroups: comp.unix.xenix,comp.unix.wizards
Subject: Re: Errors in PS
Message-ID: <15827@andante.UUCP>
Date: 5 Feb 89 23:42:21 GMT
References: <19496@lll-winken.LLNL.GOV> <341@belltec.UUCP> <667@pcrat.UUCP> <464@oglvee.UUCP> <9593@smoke.BRL.MIL> <8869@alice.UUCP> <951@auspex.UUCP>
Reply-To: raf@andante.UUCP (Roger Faulkner)
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 52

In article <8869@alice.UUCP> debra@alice.UUCP (Paul De Bra) writes:
>In article <9593@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>
>>Yes; fixed in SVR4 (I think).  Not with more system calls, though.
>>Read the paper "Processes as Files" in one of the USENIX proceedings.
>
>This "Processes as Files" way of implementing ps, as done in the Eight
>and Ninth edition Unix, does not guarantee flawless behaviour of ps though!

The /proc process filesystem as implemented in SVR4 differs in
detail, not in concept, from Eighth and Ninth Edition Unix systems.
In particular, there is one ioctl() operation that fetches all of
the information needed by ps(1).  ioctl() operations are guaranteed
to be atomic wrt the target process, so what you get is a flawless
snapshot of the process at the moment of the ioctl().

The comment in the ps(1) man page:
     Things can change while ps is running; the picture it
     gives is only a close approximation to the current state.
continues to be true wrt the full ps(1) listing.  To have
ps(1) stop the whole system (except itself) in order to
give a correct total snapshot would be overkill (i.e.,
users would undoubtedly kill their AT&T representatives).

Guy Harris's description (article <951@auspex.UUCP> guy@auspex.UUCP)
of the operation of /proc is correct (and lucid).  However, in the
SVR4 implementation the security provisions are more stringent:

- Except for the super-user, an open() of a /proc file will fail
  unless both the user-id and the group-id of the caller match
  those of the target process and unless the process's a.out is 
  readable by the caller.
- Setuid and setgid processes can be opened only by the super-user.
- An open filedescriptor will become invalid if the target process
  exec()s a setuid/setgid or unreadable object file.  Any operation
  on an invalid filedescriptor (except close()) returns an error.
  (Previous implementations either failed the target's exec() or
  silently disallowed the setuid/setgid, causing an inspected
  process to malfunction.)

In article <464@oglvee.UUCP> jr@.UUCP (Jim Rosenberg) writes:
>I should be able to read section 2 of
>the man pages and bang out a respectable ps without that much work.

With /proc, you would be able to do this (provided you can be
super-user on your system).  You'll have to read a different
section of the manual, though.  It will be either 4 or 7.

Disclaimer:  I don't officially represent AT&T, my opinions
are my own, but what I have described to you is fact.
	Roger A. Faulkner
	allegra!raf