[Plash] Plash 1.8: first X11 support; builds glibc from scratch

[Mark Seaborn]

There's a new version of Plash, 1.8.  You can get it from:
http://www.cs.jhu.edu/~seaborn/plash/plash.html

One important improvement is that it's now possible to build Plash's
modified glibc from scratch without manual intervention.  There is now
a Debian source package, and I've added man pages.

Please note that I have swapped the precedences of the "+" and "=>"
argument list operators in the shell.  "=>" now binds more tightly
than "+".  This means that:
  command a => b + c => d
means the same as:
  command { a => b } + { c => d }
This has come out of practical experience of using the shell.


The shell now has an option for automatically granting programs access
to the X11 Window System.  When this is switched on, a command such
as:

  xpdf foo.pdf

is equivalent to:

  xpdf foo.pdf + ~/.Xauthority => /tmp/.X11-lock

This option is switched off by default because X11 is not secure!  X
servers provide no isolation between the clients connected to them.
One client can read keyboard input that goes to other clients, grab
the screen's contents, and feed events to other clients, including
keypress events.  So *potentially*, an X client can gain the full
authority of the user.

The solution to this will be to write a proxy, through which an X
client will connect to the X server, which will prevent it from
interfering with other X clients.

Here's how to switch X11 on:

Either:  From the shell, enter:

  plash-opts /x=options 'enable_x11' 'on'

Or:  To enable it for all shell sessions, you can create a file
"~/.plashrc" file containing this (note the semicolon):

  plash-opts /x=options 'enable_x11' 'on';

and start the Plash shell with the command:

  plash --rcfile ~/.plashrc

(In order to make it as predictable as possible, Plash doesn't read
any options files by default, so you have to specify options files
explicitly.)

I have changed how shell options are set.  There used to be an "opts"
command in the shell which would open an options window using Gtk.
There is now an external program which does the same thing, which you
can run from the shell (so the shell is no longer linked with Gtk).
You can run this program with the command:

  plash-opts-gtk /x=options

The shell creates an object -- which it binds to the "options"
variable -- for setting and getting options.


Lastly, Plash now has partial support for using open() on directories.
XEmacs can now run under Plash.  XEmacs will just open() a directory
and then close() the file descriptor it got, and this is all Plash
supports at the moment.

A complete solution would involve virtualising file descriptors, so
that every libc call involving file descriptors is intercepted and
replaced.  This would be a lot of work, because there are quite a few
FD-related calls.  It raises some tricky questions, such as what bits
of code use real kernel FDs and which use virtualised FDs.  It might
impact performance.  And it's potentially dangerous: if the changes to
libc failed to replace one FD-related call, it could lead to the wrong
file descriptors being used in some operation, because in this case a
virtual FD number would be treated as a real, kernel FD number.
(There is no similar danger with virtualising the system calls that
use the file namespace, because the use of chroot() means that the
process's kernel file namespace is almost entirely empty.)

However, a complete solution is complete overkill.  There are probably
no programs that pass a directory file descriptor to select(), and no
programs that expect to keep a directory file descriptor across a call
to execve() or in the child process after fork().

So I will be using a partial but safe solution:  When Plash's libc
needs to return a directory file descriptor to the main program, it
does open("/dev/null") and returns a real file descriptor.  This has
the effect of allocating a FD number (so the kernel can't re-use the
slot), and it provides a FD that can be used in any context where an
FD can be used, without any harmful effects -- at least, as far as I
know.

If a program uses fchdir() or getdents() on the resulting FD, it will
just get an error in the current version of Plash.  If I want to
implement these calls in the future, it will just be a matter of
having open() record in a table any directory FDs that it returns;
fchdir() and getdents() can do a lookup in this table.  dup(), dup2(),
close() and fcntl() (with F_DUPFD) will have to be changed to keep
this table up-to-date.  Maybe execve() should give a warning if there
are FDs that won't be kept in the new process.  Frequently-called
functions like read() and write() will not have to be changed.

Mark