BSD & Sys5 Job Control

[ECSC68 S Brown CS]

In article <164 at myab.UUCP> lars at myab.UUCP (Lars Pensj|) writes:
>
>It is quite possible to make csh use the sxt devices. We have done
>such an implementation, and are now using csh in place of sh.
Strangely enough, I've done the same for sh (and of course am using 
it in place of csh :-) ).

>
>Result:
>
>++++	Possibilities to switch between 7 jobs and let them
>	run in the background.
Seven because the shell itself is using channel 0 for input/output of
commands - but in that case, there is a little problem with terminal
groups; namely:
    The shell can't just keep its old "real" tty as its controlling terminal
    because this cannot be accessed (via read(2)) any more once an sxt
    cluster has been multiplexed onto it, so the shell will have to take
    over sxt channel 0 for its own purposes. The only way of getting a
    new terminal as your controller is to do the following:
	1. Do a setpgrp().
	2. Open a new terminal.
    So, you would naturally think that the way to get an sxt chan 0 for your
    shell's controller would be to do this:
	1. setpgrp();
	2. open("/dev/sxt??0",2);
    All well and fine - until you try to multiplex the rest of the cluster
    onto chan 0 (SXTIOCLINK ioctl) - for this to work, your controlling
    terminal must be a "real device" (not an sxt), so you can't put the
    setpgrp() there. And if you don't do that, then sxt??0 is not set up
    to be your controller. 
    Ok, next attempt is probably
	1. fd=open("/dev/sxt??0",2);
	2. ioctl(fd,SXTIOCLINK,...);
	3. setpgrp();
	4. open("/dev/sxt??0",2);
    ie, re-open the chan-0 device. But this falls over because of the
    "ownership" problem with sxt's.
	[Brief summary: 
	    A standard non-priviliged user will need to be able to open
	    these sxt devices in read/write mode. But once they have done
	    so, nobody else had better be able to do so! (for obvious
	    security reasons). Also, programs such as shl are pretty untidy
	    about the mess they leave behind them - shl chown()'s the sxt's
	    to the userid of whoever is using them, but doesn't chown back
	    to some standard user (root?) afterwards. So, if 16 people logged
	    in and ran shl and logged out again, then all the sxt devices
	    will be owned by them and only them - nobody else ('cept root)
	    has a hope of ever being able to access them again.
	    (Subsiduary remark:
	        My solution to this (pretty crappy, I know), is to have a setuid
	        service-program which "allocates" sxt's by chowning them to the
	        real-uid of the caller. The job-control shell will then access
		an sxt device cluster by doing
		    a) execute this "sxt-allocator".
		    b) go through all the sxt's, trying to open each cluster's
		       channel-0. If the open succeeds, then you've got one.
		       It it fails with errno==EBUSY then keep on trying.
		       If it fails with errno anything else, then give up and
		       that particular instance of the shell can't have any
		       job-control.
		    c) multiplex the subchannels.
		    d) set chan-0 to exclusive-use (TIOCEXCL ioctl) to stop
		       anyone else from stealing it from under you.
		    e) ......
		Another advantage of this is that the setuid allocator can
		then modify utmp (you can't, 'cos you aren't root). If the
		shell calls the allocator again (when its finished being a
		shell), then utmp can be changed back again - its all pretty
		transparent.
	    )
	]
    Or perhaps its not, actually. I'll have to think about this again :-)
    Anyway to get back to the original argument... you could fix this
    by making channel-1 the controlling terminal - but then you can only
    have 6 remaining subchannels, which isn't too many..

>
>-	Csh doesn't modify tty name in wtmp. We "hacked" getlogin() to
>	do it another way, and relinking all programs using it.
You'd also have to "hack" all the functions in the getut(3) family.

>
>-	Csh have problems handling type ahead, because typed characters
>	are associated to the sxt device attached to the current
>	process. When the process exits, csh has to read them back from
>	this device.
That's ptetty straightforward - it means that anything typed while a
process is getting 'round to dying off can be picked up by the shell
and read as part of the next command - but you can't type further input
and expect it to get picked up by the next command, 'cos it won't be:
Example:
    $ ex filename 		# edit (or whatever) something)
    :q				# quit
    mail fred			# while its dying, start typing next command
    hello			#   ... and type some data as input?
    hi fred, this is mail.....
    ^D
    $				# shell-prompt, then it executes "mail"
    Subject:			#   ... huh? why is it waiting? I thought
				#   ... I'd given it some input, it seems
				#   ... to have forgotten that!
    ^D
    $ hello: not found		# oh look! it stored up what I typed in
    $ hi: not found		# the _shell_'s input buffer!
Of course, if SysV provided a TIOCSTI ioctl call like BSD does, then this
could be fixed by the shell's sticking the extra characters into the
input queue of whatever sxt device is running next :-)

>
>-	A process can not know whether it is blocked or not.
Well...., if the sxt controller channel (chan 0) were left open, then
processes could do a SXTIOCSTAT ioctl on it and look for themselves.
But this would be gross. :-)


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Simon Brown
Department of Computer Science, University of Edinburgh, Scotland, UK.
UUCP:  ...!decvax!seismo!mcvax!ukc!{cstvax,its63b}!simon
JANET: simon at uk.ac.ed.{cstvax,its63b}