John Hawkinson wrote:

>Dmitri Nikulin <setagllib@optusnet.com.au> wrote on Sat, 13 Nov 2004
>at 16:45:38 +1100 in <41959F82.4020408@optusnet.com.au>:
>
>
>  
>
>>One thing that is definitely a very good privacy/security feature is 
>>what FreeBSD implemented that can prevent users seeing the PIDs (or 
>>indeed any info) of processes they don't own, via ps or top or whatever 
>>else. Nobody can argue that this is a Good Thing on a shared shell 
>>server. Whether or not this is easy to implement cleanly is another matter.
>>    
>>
>
>It can certainly be argued that it is Good Thing on a shared shell server
>that users can see each others processes. It promotes responsible system
>usage, the ability of users to investigate problems without invoking
>administrators, encourages a belief in a shared system that you don't
>mess up for other people, and may have positive social benefits.
>
>It's not a slam dunk, but it can certainly be argued that it viewing
>process you don't own is a Good Thing.
>
>--jhawk
>
>  
>
You'll have to explain further. I've never heard of a need to see that 
someone else is running vi or emacs for doing their work, in terms of a 
social benefit. In fact a lot of privacy issues occur because people see 
what others are doing, especially in cases where silly software designs 
(and I'm sure there are still programs like this left) involve passwords 
or private emails/etc being provided on the command line. If someone is 
using links/elinks/lynx by URL directly, it can be considered invasion 
of privacy to see what site they're looking at. Same for email 
applications where a recipient was specified on the command line.

Opposing pid walling for the same reasons as opposing tty snopping 
doesn't make much sense to me. They're essentially opposites, with one 
giving privacy between users and the other giving omniscience to root.

If responsible system usage involves not loading the system while many 
others are working, there are other mechanisms for that. Looking at load 
averages, for instance. But I doubt any users will need to heavily load 
a shared system anyway - as a courtesy any number-crunching should be 
done on private (or dedicated) machines, and compilations during 
software development are usually minimal load because make avoids 
redundancy. Apart from this, nothing should load the system so badly. 
Dozens of people coded happily on shared PDPs which are much weaker than 
any servers we may have, and they didn't have NetBSD 2's winning 
responsiveness.