ijk@hou5e.UUCP (Ihor Kinal) (10/17/83)
The following is a question from a recent PhD qualifying exam that I am having difficulty in answering in great depth. I'm interested if anyone could add something to my analysis. Question: " One design decision within an o.s. is where to put the command language processor. ( Some times this component is called the JCL interpreter or the shell). Consider two systems A) Put the command language processor at the inner most level of the O.S. as a special priviledged program. B) put it as a user process. How would the selection of A or B effect the design of the remainder of the operating system." Analysis: Obviously case B allows for greater user flexibility with differrent shells available for different users. Security seems the most important criterion, since you must protect the shell from being replaced with a trojan horse that would log people out and then back in (therebye learning their passwords). More difficult to do this in case A, since then you would have to basically replace the entire o.s. On the other hand, in case A, any unusual exceptions that were not caught properly could easily put the user in an unprotected mode with possible superuser priviledges ( I think OS 360 had such a problem). Since the shell is separate, even a bug in its execution would probably only core dump the user, and not affect the kernel. That's about all that I can think of - it would seem that the rest of the O.S. would be pretty transparent to this sort of thing. If you can think of anything else, or know of any texts that even discuss something of this type (and I've looked through several) then I would appreciate knowing about this. Ihor Kinal ATTIS, Holmdel NJ hou5e!ijk (talks to most Holmdel Bell Labs machines, ariel, ho* ) Thanx in advance.
barmar@mit-eddie.UUCP (Barry Margolin) (10/18/83)
I think that the trojan horse issue is a red herring (to throw together a few euphemisms). If someone can replace someone else's shell on a system where the shell is a user program, then he can just as easily get the victim to execute a program which simulates the shell on a system where the real shell is in the kernal; both of them require making the victim execute a command. If this is not the case, then the OS has serious security problems. Therefore, since the user-level shell provides more flexibility to those who need it, it is the obvious choice. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar
mark@umcp-cs.UUCP (10/21/83)
A couple of other things that would be affected by where the shell was:
-A user shell would mean that the rest of the operating system
had to bring full power out to the user level. This would mean that
user programs to do strange operating system things would be writtable:
a plus!
-Kernel shells can keep privileges to themselves for which there
is no possibility of the user ever doing. This can make for
a user friendly system if other things are right, but it is
definitely expert-unfriendly. There may be some things which
cannot at all be programmed at all except through baroque
sets of command language calls which may be impossible to do
from within a users program.
(One of the things that sold me on Unix--I knew that whatever
the shell could do I could do, and so whenever it did something
I really admired I would go read the code to find out how.
This was not true on any previous operating system I had worked on.)
--
spoken: mark weiser
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!mark
CSNet: mark@umcp-cs
ARPA: mark.umcp-cs@CSNet-Relayron%brl-vgr@sri-unix.UUCP (10/22/83)
From: Ron Natalie <ron@brl-vgr> Just goes to show that CS professors have as bad a grasp on semantics as the rest of the industry. (The user command interpreter probably does effect the design of the operating system (or maybe not), but the analysis indicates how it affects the design.) Just nice to see people in high places make the same dumb mistakes that the rest of us make. -Ron