[Question] Having brains again after being headless?

Ian Piumarta ian.piumarta at inria.fr
Fri Dec 6 20:52:26 UTC 2002


Hi Stephen,

On Fri, 6 Dec 2002, Stephen Pair wrote:
> Actually, the signaling method sounds appealing...what are the Unix
> security rules regarding signaling of processes?

A process owned by the superuser can send any signal to any process.  
Other processes (e.g., `kill' launched from a shell) can only send signals
to a process whose real or effective UID matches that of the sending
process.  In effect, a user can only send signals to their own processes.

(The only exception [no pun intended] is SIGCONT, which can be sent to any
descendant of the sending process regardless of ownership.)

> It sounds like it might be a little safer from a security standpoint
> to use a signal rather than a socket.  OTOH...I still need to be able
> to communicate *which* display on which to capitate the Squeak
> display.

Signals don't carry any context around with them, so something else would
be required.  One possibility would be to have the signal reconnect the
default display and have the listening socket simply change the VM's idea
of what the default display should be.  There would still be a window of
vulnerability (between writing the display name to the socket and sending
the signal) but at least your script could reduce that to milliseconds,
and only you (or root) would be allowed to send the signal.

Simple security could be added by setting a password in the image that
you'd have to send to the socket along with the display name.  This is
better than nothing but, without imposing the use of a "helper" program,
the password would be sent plaintext.

Entirely secure communication (and permission checking) is possible by
various different approaches, but would require a helper program.

> > As for (un)loading (or reconfiguring) huge piles of Unix VM 
> > support code (GUI or otherwise) on demand, watch this space. ;)
> 
> Yes!  Sounds cool!  What about opening multiple displays for a single
> Squeak process???  :-))

This has already been possible (Mike Rueger might remember seeing multiple
X11 and VNC displays running in parallel on a single VM a year or so ago)
but the code never made it into the mainstream release, and it only
replicated the single Squeak window rather than allowing multiple,
independently-windowed worlds.  (It would still be useful for "multicast"
demonstrations though, especially with VNC doing the multicasting. ;)

> I realize that there is a lot of gutting that'll probably have to happen
> on the Smalltalk side to allow multiple displays, but I wouldn't think
> that making the display support plugin handle opening multiple windows
> be too difficult would it?

The parallel display stuff worked by encapsulating the various i/o
subsystems (display for example) into components (so everything that is
declared "static" in the current code was instead bundled into a
malloc()ed struct) and allowing any number of components to be
instantiated in parallel for a given subsystem.  But you're right that it
would be extra work to connect these to independent entities within the
image.

> The gutting can happen later.

Or you could start playing right away.  The FFI code is already capable of
creating new X11 windows and drawing into them.  Add the method

	Form>>flushRegion: aRectangle toWindow: aX11Window

and you're on your way.  (Provided you're not running on Darwin where
there's an unfortunate problem with Window IDs being mistaken for pointers
into the object memory, causing the FFI primitives to fail a "sanity
check".  [If Andreas is reading, I'm still hoping for a cheap and cheerful
fix for this.])

Regards,

Ian





More information about the Squeak-dev mailing list