Question abt /etc/crash & proc struct

[Mark Brown]

shore at theory.TC.Cornell.EDU (Melinda Shore) writes:
>moody at snap.austin.ibm.com writes:
>>No one would want user mode programs to have access to this structure.
>
>It is not at all clear what you mean by this.  If you mean that no
>program outside the kernel should be able to access the proc table,
>that's obviously incorrect.  If you mean that the pages containing the
>proc table should be protected by the mmu, that's less obviously
>incorrect, but incorrect nevertheless.

[NOTE: most of what I know about the /dev/kmem aspect of system security
vis-a-vis NCSC standards I learned by word-of-mouth. My opinions on this
subject, therefore, are not authoritative.]

Not so obvious at all, I've found.

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.

Note, for example, that PIDs on the 6000 are assigned in a "random"
order, to hide information that can (I've been told) be used against
the system.

Mr. Haugh knows a *lot* more about the details of these issues than I,
and can probably be persuaded to explicate them....

>One of the very basic paradigms in Unix is that of a file.  Granted,
>...
>virtual memory.  Access permissions are set in the inode, not the

Unless you are looking at Access Control Lists and such.

-- 
DISCLAIMER: My views may be, and often are, independent of IBM official policy.
Mark Brown       IBM PSP Austin, TX. |     Crazed Philosophy Student
(512) 823-3741   VNET: MBROWN at AUSVMQ |   Kills 15 In Existential Rage!
MAIL: mbrown at testsys.austin.ibm.com  |                      --tabloid headline