Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!uw-beaver!cornell!batcomputer!theory.TC.Cornell.EDU!shore
From: shore@theory.TC.Cornell.EDU (Melinda Shore)
Newsgroups: comp.unix.aix
Subject: Re: Question abt /etc/crash & proc struct
Keywords: crash kernel proc kmem
Message-ID: <1991Jun22.031525.24642@batcomputer.tn.cornell.edu>
Date: 22 Jun 91 03:15:25 GMT
References: <8633@awdprime.UUCP> <1991Jun21.151601.29883@batcomputer.tn.cornell.edu> <8693@awdprime.UUCP>
Sender: news@batcomputer.tn.cornell.edu
Organization: Cornell Theory Center
Lines: 22
Nntp-Posting-Host: theory.tc.cornell.edu

In article <8693@awdprime.UUCP> mbrown@testsys.austin.ibm.com (Mark Brown) writes:
>Actually, there are very valid reasons for not allowing user programs
>access to the proc table information (excepting in a very limited
>fashion). They have to do with system security and user information
>security on that system.

Right.  Which is why you set the permission bits on device special
files for memory so that they can't be read or written by a random
user.  By changing the rules so that access to memory is controlled
at a much lower level you break a basic Unix idiom and grossly
diminish both the flexibility and power of the file paradigm.  Cray
made this mistake in the block multiplex driver in early versions of
Unicos, and they ended up changing it back.

>>Access permissions are set in the inode, not the
>Unless you are looking at Access Control Lists and such.

With the exception of AFS, the acls I've seen *have* been permission
bits in the inode.
-- 
                    Software longa, hardware brevis
Melinda Shore - Cornell Information Technologies - shore@theory.tn.cornell.edu