freedman@granite.cr.bull.com (Jerome Freedman) (01/09/90)
I am currently involved in a project requiring the management of two or more processes using the same terminal, but under control of a server. I believe that job control is required, but my initial attempts at implementing the project have met with (dismal) failure. This is most discouraging, especially in the light of successful attempts using the same implementation on two other manufacturer's UNIX machines. Specifically, I wish to use the following system calls: ioctl(0, TIOCSPGRP, &pid) kill(pid, SIGSTOP); kill(pid, SIGCONT); Any ideas on why these calls seem to behave differently on the HP than on other systems?
rml@hpfcdc.HP.COM (Bob Lenk) (01/16/90)
In <1990Jan8.203600.6950@granite.cr.bull.com> freedman@granite.cr.bull.com (Jerome Freedman) writes: > Specifically, I wish to use the following system calls: > > ioctl(0, TIOCSPGRP, &pid) > kill(pid, SIGSTOP); > kill(pid, SIGCONT); > >Any ideas on why these calls seem to behave differently on the HP than on other >systems? Most likely the difference is that BSD permits any process that has a terminal open to perform TIOCSPGRP, while HP-UX imposes some security restrictions based on the caller and the target process group ID. The exact nature of the checks is documented under termio(7). In the 7.0 release these checks are the same as for the POSIX tcsetpgrp() call; in earlier releases they had a similar intent but were somewhat different. It would not surprise me if other implementations impose similar restrictions when they conform to POSIX (or when they beef up security). Note also that the setpgrp() and getpgrp() calls are different from BSD. If the program is linked with -lBSD there are calls which are syntactically the same and semantically similar, but they also impose more security checks than the BSD versions (the setpgrp2() and getpgrp2() calls in libc are the same calls with names that don't conflict with System V). If by any chance the system is a series 300 earlier than release 6.5, job control is not supported at all. On those systems the above calls should fail to compile because the constants used are not #defined. Bob Lenk rml@hpfcla.hp.com hplabs!hpfcla!rml