berry@socrates.umd.edu (Joseph Berry ) (06/19/91)
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 is joe@ssgltd.com. You can call me at 301-764-5668. Thanks, Joe Berry
shore@theory.TC.Cornell.EDU (Melinda Shore) (06/19/91)
[]
"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
Melinda Shore - Cornell Information Technologies - shore@theory.tn.cornell.edumoody@snap.austin.ibm.com (06/20/91)
In article <1991Jun19.151832.17038@socrates.umd.edu> berry@socrates.umd.edu (Joseph Berry ) writes: >I cannot access the data structure 'proc' either programmatically or No one would want user mode programs to have access to this structure. >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. >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. -- James Moody aixnet:moody@moody.austin.ibm.com Personal Systems Programming Austin VNET:MOODY@AUSVMQ AIX Field Support - Level 3 internet:moody@aixwiz.austin.ibm.com
shore@theory.TC.Cornell.EDU (Melinda Shore) (06/21/91)
In article <8633@awdprime.UUCP> moody@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. 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 Melinda Shore - Cornell Information Technologies - shore@theory.tn.cornell.edu
mbrown@testsys.austin.ibm.com (Mark Brown) (06/22/91)
shore@theory.TC.Cornell.EDU (Melinda Shore) writes: >moody@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@AUSVMQ | Kills 15 In Existential Rage! MAIL: mbrown@testsys.austin.ibm.com | --tabloid headline
berry@socrates.umd.edu (Joseph Berry ) (06/22/91)
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
shore@theory.TC.Cornell.EDU (Melinda Shore) (06/22/91)
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
jfh@rpp386.cactus.org (John F Haugh II) (06/24/91)
In article <8693@awdprime.UUCP> mbrown@testsys.austin.ibm.com (Mark Brown) writes: >shore@theory.TC.Cornell.EDU (Melinda Shore) writes: >>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 Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "UNIX signals are not interrupts. Worse, SIGCHLD/SIGCLD is not even a UNIX signal, it's an abomination." -- Doug Gwyn
probe@athena.mit.edu (Richard Basch) (06/27/91)
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