peter@hydrovax.nmt.edu (Peter A. Blemel) (11/13/89)
Hi Folks, I have spent much time trying to figure out why Interleaf kills the system. We have a 135 and when tps starts, everything else stops. I tried nicing (sp?), sticky-bitting, and even stripping the symbol table. I wish I were more of a systems type. Many hours and faxes into the search, IBM tells me that the program runs ON the VRM at an elevated priority. I checked, and sure enough -- the program starts niced and then drops to prio 10. I have looked, and nothing is setuid root (I have looked for any and all 'tps*' and 'leaf*' execs), the owner (leafadm) is now in its own group, and I run it from an unpriveleged account. It still can change its nice value. I was under the impression that only a priv'd account could change the nice value of an executing program. If this is correct, then how can Interleaf change its priority from a vanilla account? Is this an indication of some unknown security hole (how is it getting authorization to elevate its priority)? The core exec is tps4.0. Issuing ps -ael in a 'while true' loop shows that tps4.0 is the only interleaf related program executing for a second or so before and at the time the nice value changes. This thing kills a very expensive machine. I'd really appriciate any information on how to lower its prio and free the CPU. Is the permission set in the a.out header (a.out.h or vrm.h)? Can I modify the header to fix the problem? Thanks, Peter ----- peter@hydrovax.nmt.edu peter@amber.nmt.edu
njs@scifi.UUCP (Nicholas J. Simicich) (11/20/89)
In article <3485@nmtsun.nmt.edu> peter@hydrovax.nmt.edu (Peter A. Blemel) writes: > Many hours and faxes into the search, IBM tells me that the program >runs ON the VRM at an elevated priority. I checked, and sure enough -- the >program starts niced and then drops to prio 10. I have looked, and nothing >is setuid root (I have looked for any and all 'tps*' and 'leaf*' execs), the >owner (leafadm) is now in its own group, and I run it from an unpriveleged >account. It still can change its nice value. > > I was under the impression that only a priv'd account could change the >nice value of an executing program. If this is correct, then how can >Interleaf change its priority from a vanilla account? Is this an indication >of some unknown security hole (how is it getting authorization to elevate >its priority)? What is actually happening is that Interleaf is running as a monitor mode program, I believe (I've never run Interleaf, but I've seen it run from a distance of more than five feet). (Monitor Mode is a special mode which allows a running program to take over a monitor completely and use the adapter directly without stepping on other programs (X Windows, for example) which are also using the adapter directly.) AIX/RT believes that the program that is using the adapter at the console should get good, smooth, consistent performance, and so automatically nices it as it goes into Monitor Mode. I think that this is why, for example, that the X server runs at nice value 0. X is a well behaved program, and probably should be run at nice 0. It seems that Interleaf is not. (This behavior makes it difficult or impossible to debug a monitor mode program which is in a loop.) Thus, Interleaf is not changing its own nice value, that is being done for it by AIX. Any user that can go into monitor mode can get niced in the same way. If you think that this behavior is a bug, then call support. You might be able to get Interleaf to reset its nice value whenever it is cranked, but I don't know. If Interleaf runs under X, then geting that version might work for you as well, as the program would no longer be in monitor mode. -- Nick Simicich --- uunet!bywater!scifi!njs --- njs@ibm.com (Internet)