File descriptors for TTYs under Unix do not behave like capabilities in the sense that the kernel takes a process's "process group" into account when the process does IO on a TTY file descriptor. This is part of the Unix job control mechanism. A process will be stopped (with SIGTTIN) if it tries to read from a TTY when it is not part of the TTY's current process group.
I don't think this is a good design. So far, however, it has not a problem because the processes started by `exec-object' can simply set their process group ID to the one specified in the "exec" invocation. That lets them read input from the terminal.
However, processes also have a "session ID". Typically, the processes running under a given terminal window run in their own distinct session. A process cannot set its process group ID to a process group that belongs to a different session. So if an exec-object instance E, started from one terminal window W1, is invoked by a process in another terminal window W2, E won't be able to start a process P that can read input from the user in W2, even if P has the appropriate TTY file descriptor. This may be a problem in the future.
I can see two ways around this:
Just arrange for all the relevant processes to be running under the same session ID. This would only work if we're not using existing terminal emulators (xterm, gnome-terminal, etc.). It might not work at all.
Virtualise IO on file descriptors to use method calls on objects instead. There would be a lot of libc functions to modify in order to do this properly, but this has other uses.
You can start a process via the shell using an object invocation, and you can stop the process by pressing Ctrl-Z, but the shell is not informed that the process has been stopped, so the shell will not return control to the user and display a prompt.
This needs to be fixed. It is a deficiency in the specification of the "Exeo" method call.
exec-object does not set the current working directory of the processes it starts.
exec-object doesn't provide any control over the arguments and environment variables it passes to the processes it starts.
exec-object doesn't start its child processes with a different UID, so the child process could kill it, ptrace() it, etc. (exec-object should use "run-as-anonymous" like the shell does.)
The shell does not provide a mechanism for sharing object references with other instances of the shell, with other users, or across the network.
The shell does not allow for recursive definitions using "def".
The shell only supports "capcmd CMD ARGS..." where CMD is an executable file, but not where CMD is an executable object, and it doesn't support running CMD in the standard Unix way (as the `!!' syntax does).
A "capcmd !! CMD ARGS..." expression would allow the use of existing setuid executables from programs running under Plash.
A "capcmd VAR ARGS..." expression would make it possible to have a single process provide multiple executable objects, ie:
def factory_maker = capcmd factory-maker-maker def echo = capcmd factory_maker '/bin/echo' ... def ls = capcmd factory_maker '/bin/ls' ...