Question abt /etc/crash & proc struct

Question abt /etc/crash & proc struct

Post by Joseph Berr » Fri, 21 Jun 1991 00:18:32



I cannot access the data structure 'proc' either programmatically or
from within /etc/crash.  The address of proc is 0xE3000000. When I
use /etc/crash, it gives me nothing (just the address itself). When
I try to lseek to that address I get an error (other kmem variables
work fine -- it's not a permissions problem). There's something I'm
missing about accessing addresses in such a high address space.
For whoever knows the answer, I'm going to guess it's something trivial.
Only what??!!

Please let me know if you have the answer.  My normal e-mail address

Thanks, Joe Berry

 
 
 

Question abt /etc/crash & proc struct

Post by Melinda Sho » Fri, 21 Jun 1991 01:06:35


[]
"proc" is of type "struct proc *".  That is to say, it contains
the address of the data you want, not the data.
--
                    Software longa, hardware brevis


 
 
 

Question abt /etc/crash & proc struct

Post by mo.. » Fri, 21 Jun 1991 22:51:59



Quote:>I cannot access the data structure 'proc' either programmatically or

No one would want user mode programs to have access to this structure.

Quote:>from within /etc/crash.  

This can be done if you're looking at a dump.  Use the 'dump' subcommand in crash.  
Various components are listed.  Enter '1' for 'proc'.

The result is a list of ids which may be selected.  They looks something like:

1 0p
2 0u
3 1p
4 1u
....
...

or something like that.  The number of entries depends on the number of processes
running on your machine at the time the dump was taken.

The right column corresponds to a process slot (use the 'proc' subcommand
to see which process slot you may be interested in).  The 'u' and 'p'
suffixes are for 'user area' and 'proc table entry' respectively.
In the above example, by entering 3, I get the proc table entry for
the process in slot 1.  

For a LIVE system, you might look at the getproc, getuser system calls.
See procinfo.h.

Quote:>There's something I'm
>missing about accessing addresses in such a high address space.

You don't have addressibility to the process table memory segment in user mode.

--



 
 
 

Question abt /etc/crash & proc struct

Post by Melinda Sho » Sun, 23 Jun 1991 00:16:01



>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.

One of the very basic paradigms in Unix is that of a file.  Granted,
it hasn't been implemented very consistently (particularly in BSD),
but the basic notion is that most system objects can/should be able
to be treated like a file, including memory.  You should be able to
open, read, write, and lseek around in both physical and kernel
virtual memory.  Access permissions are set in the inode, not the
page table (sheesh), and users are granted permission to read, write,
etc., memory just as they are with files - on the basis of the
permission bits in the inode.  Taking away that facility is *not* an
improvement.

That's not to say that there shouldn't be system calls to copy kernel
data structures out to user space.  They do simplify programming and
considerably improve the performance of programs that grab data out
of the kernel.  That still doesn't justify removing a flexible,
powerful, and idiomatic facility.

Also, note that some of us are running AIX/370 and don't have getproc().
--
                    Software longa, hardware brevis

 
 
 

Question abt /etc/crash & proc struct

Post by Mark Bro » Sun, 23 Jun 1991 06:32:08




>>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....

Quote:>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


 
 
 

Question abt /etc/crash & proc struct

Post by Melinda Sho » Sun, 23 Jun 1991 12:15:25



>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.

Quote:>>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

 
 
 

Question abt /etc/crash & proc struct

Post by Joseph Berr » Sun, 23 Jun 1991 07:07:03


Melinda and everyone else...

I got a very nice answer from an IBM software representative in Munich that
understood and told me the solution to my problem.  On other UNIXs, accessing
any area in the kernel can be done by simply doing an lseek followed by a
read of the structure of interest.  I had the address of the PROC structure
from the nlist procedure (indirect, of course).  That address was BIG.  Lseek
failed, /etc/crash failed (when using 'od' as opposed to the formatted
proc output).  

I finally found the answer both by Werner's assistance and by use of
infoexplorer (although the function I wanted wasn't exactly documented
as it should have been).  The key was use of procedure 'readx'.  Lseek cannot
access an address that is in the address space above 2 gigabytes; my pointer
was out there.  For that, you must use readx.  Something to remember when
you find yourself needing direct access of that table <GRIN>.  THanks to
everyone for their suggestions.

Joe Berry

 
 
 

Question abt /etc/crash & proc struct

Post by John F Haugh » Tue, 25 Jun 1991 22:21:45




>>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....

Gee, thanks.  I'll remember your name next time I can find some way
to pick on you ;-)

There is no "real" reason to deny the capability in an abstract sense.
That is, there is no way to construe what the Orange book (or any other
security text for that matter) says to imply that denying access to
the proc structure to all processes is a requirement for system
security.

What the Orange book talks about is authorization to access particular
information.  Clearly "write" access must be denied - that much is
spelled out for B1 in section 3.1.3.1.1 - the system must maintain a
"domain" that is free from tampering.  Read-only access prevents
tampering, therefore.  Section 3.1.2.1 says the system must allow
access to authentication data only to accessed by authorized programs.
Setting the permission bits on the device file and putting people in
the authorized groups (or giving away set-ID privileges) would be
"authorization".

The real reasons for denying access are all "portablity" problems.
Back when I was having this argument with certain architects, their
claim was that the user would have to recompile their non-portable
programs every time the system changed and therefore allowing access
was useless.  I maintain that this argument smacks of patronization.
This is precisely what everyone does already, so IBM isn't saving
anyone any time they haven't already committed themselves to spending.

It is good that IBM provided getproc() and getuser(), and I was one
of the people pressing to have both documented - but that is not
enough.  The traditional methods for getting at the proc table must
still be supported.  There is value in being "the same", just as
there is value in being "different".  Preserving de facto standard
access methods is too important to be brushed away by a "value added"
feature.
--
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh

"UNIX signals are not interrupts.  Worse, SIGCHLD/SIGCLD is not even a UNIX
 signal, it's an abomination."  -- Doug Gwyn

 
 
 

Question abt /etc/crash & proc struct

Post by Vic Abe » Wed, 26 Jun 1991 07:33:55


As an illustration of the use of getproc(), getuser() and the reading of
kernel structures via /dev/kmem, there is an AIX 3.1.[35] version of ofiles
available via anonymous ftp from:

        j.cc.purdue.edu         (128.210.9.2)

in pub/AIX3_ofiles.tar.Z.


 
 
 

Question abt /etc/crash & proc struct

Post by Richard Bas » Fri, 28 Jun 1991 15:48:23


There are lots of reasons why a person may want to access the proc structure.
We, at MIT, find that logged out users sometimes still have processes running
on "public workstations".  Part of our workstation re-initialization between
users includes running a program that hunts for such processes and kills them
on what are considered to be "public workstations".

Of course, this could be done in shell-scripting, but it is not nearly as
elegant or accurate as doing it in a C program.

The statement of not being able to access the proc structure from user mode
has to be flawed, otherwise "ps" would not work.  The catch is that you have
to use the readx() call, and in the use of bit 31 (the sign bit).  I do not
recall how we fixed the problem, as I do not have the source in front of me
at the moment...

-Richard Basch
MIT Athena Systems Development

 
 
 

1. proc & user structs on RS/6000

Does anyone know how to obtain the proc and user structs for all
existing processes on an RS/6000? strings of /bin/ps does not contain
/unix or /dev/kmem, so I suspect the existance of a magic syscall, but
I cannot find any trace of such.

Thanks!
        Phil Budne, Boston University

2. 'if' in zsh

3. Crash with Ftape, X11R6, & /proc/kcore

4. PCI SCSI and HD's

5. How to create /proc/net/ip_block &etc ?

6. apache and misticaly closed port

7. PPP kppp && pppd etc etc.

8. SIS 6205 and XFree86 3.2

9. Specifications & info abt. Texture Memory for Powerstorm 4D40T?

10. How do I get a (struct proc *) for the current user process (in NEXTSTEP 3.3)?

11. proc struct on Solaris.

12. Solaris /proc "struct prusage" statistics

13. : Where is command invocation stored in a proc struct?