A couple of other points that might be worth discussing for this sort of usage

a) it's way past time we stopped opening a windows when it isn't needed. No window should be created until and unless the system actually writes to the display and calls for a display update. This would enable image-controlled headlessness. RISC OS was able to cope with it 25 years ago.

b) containers. At least, so far as the currently very limited understanding of containers that I have suggests. AIUI you can make a bundle that behaves as a (nearly) separate machine and do permissions stuff to sandbox it. I'm having a bit of a hard time making much detail sense of it but I'm sure someone hereabouts can explain if in words of one syllable or less.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim The halfway point between right and wrong is still damn wrong. Compromise isn't always a solution

On 2020-04-13, at 10:45 PM, Erik Stel erik.stel@gmail.com wrote:

a) Indeed this could be something for the VM to decide. When 'deploying' the VM I would like it to be as small as possible as well. So if leaving out (unnecessary) code is possible, I'm happy to do that. Although I'm not planning to wrangle out every little byte to safe space.

It probably isn't worth putting much effort into saving space on the VM code since it is what, 1-2MB? Compare that to a likely 50-100MB for an image with Seaside etc. In the far distant past we used to have to worry about out image sizes but these days they're not really much bigger than the other kind of image that our cellphone cameras produce!

b) True as well. But that would probably also prevent the VM itself to read/write to the filesystem which is not what I want. I might (at some point) include a plugin which does some very specific file I/O. At least for logging purposes. But this is not decided yet.

I'm really not up to speed with containers stuff but I'm pretty sure you can configure being able to write to (some) parts of the filing system of your choice. Anyone out there with better knowledge of this stuff should please chime in, pointers to *good* explanations, tutorials, manuals, doc all appreciated. Googling gets far too much dross these days unless you already know a fair bit.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Original Sin is hard to find, but the digitally enhanced version is readily available.

This is interesting to me, both the minimal image and running in SqueakJS (how's that?) and loading ProCrypto-1-1-1 and ThunkStack and ParrotTalk, for now. I am currently consumed inside my port of SSL over to ThunkStack. I would love to have a link to your minimal image. Is it possible?

Kindly, Robert

On 4/14/20 3:32 PM, Erik Stel wrote:

Tim,

I agree, the effort to save bytes should not be too high.

If someone has some input/experience on using container technology to limit/sandbox the environment I'm happy to hear about it. Using the 'default' headless VM would be very beneficial wrt not having to maintain and build custom VM's.

A bit off topic, but I'm starting with a tiny image because of my use case: I'm actually starting with a very small image. Currently I have an image of 150Kb which has basic classes (*) to gets things going and a WebSocket class. Another Smalltalk image can send messages to the tiny image to get performed and the tiny can send events back. With this mechanism additional classes and methods are installed. Depending on what is installed the image can stay relative small. The tiny image is based on PharoCandle (see https://github.com/carolahp/PharoCandleSrc). The image currently runs inside a browser using SqueakJS (and thereby becomes a Javascript-engine replacement) or it runs as a NodeJS application. Pretty experimental still. I would like to use this same image as the base for the cloud instances. And probably use it for running on Raspberry Pi's as well (for users which do not have or want to use the cloud). IF experiments do work out as currently 'planned' ;-).

(*) Strings, Numbers, Collections, Process stuff (i.e. no compiler, methods are installed using bytecode)

Regards, Erik

-- Sent from: http://forum.world.st/Squeak-VM-f104410.html

Excellent, don't go until you are ready. I will keep my eye out for your announcement.

K, r

On 4/15/20 1:36 AM, Erik Stel wrote:

Robert,

I'm open sourcing everything. I hope to publish first version in coming weeks. Expect it to be somewhat volatile ;-).

Cheers, Erik

-- Sent from: http://forum.world.st/Squeak-VM-f104410.html

On Tue, Apr 14, 2020 at 02:32:18PM -0500, Erik Stel wrote:

If someone has some input/experience on using container technology to limit/sandbox the environment I'm happy to hear about it. Using the 'default' headless VM would be very beneficial wrt not having to maintain and build custom VM's.

The simplest is to run the VM with a dedicated non-root UID within the container, and configure the in-container filesystem permissions to allow said UID to write only to specific directories.

My Dockerfile:

FROM samadhiweb/pharovm:49c2617-alpine RUN addgroup -g 1099 pharoapp \ && adduser -D -u 1099 -G pharoapp -h /home/pharoapp pharoapp WORKDIR /pkg/image COPY app.image app.image RUN chown -R pharoapp:pharoapp /pkg/image EXPOSE 8081 ENV LD_LIBRARY_PATH /pkg/vm USER pharoapp:pharoapp CMD /bin/runapp.sh

Pierce

On Fri, Apr 17, 2020 at 01:11:54AM -0500, Erik Stel wrote:

This would limit the ability to write, but you can't prohibit reading the filesystem I think. The VM needs to read the image for one thing. If the VM would allow FFI or OSProcess, would it be possible to limit application execution using container configuration? Because with FFI/OSProcess a (naughty) user could try to gain access to applications or data.

Hi Erik,

My VM is built on Alpine Linux. The official Alpine Linux Docker image is about 5MB. Adding the VM and plugins (including my own custom libsqlite3.so and some other shared libraries) gives a Docker image under 20MB. The size of your application - Smalltalk image, changes if required, other artefacts - is in your control of course.

While running the application using a non-root dedicated UID does not prohibit the VM from reading the filesystem (assuming your code allows it), using Alpine Linux means there is very little in the filesystem to be read at all.

See https://www.samadhiweb.com/tags/Alpine%20Linux for some blog posts. Github here: https://github.com/pharo-contributions/Docker-Alpine

It should be possible to implement more stringent controls using Linux filesystem ACLs or Docker configuration.

HTH.

Pierce

On 2020-04-18, at 7:27 PM, Pierce Ng pierce@samadhiweb.com wrote:

On Fri, Apr 17, 2020 at 01:11:54AM -0500, Erik Stel wrote:

...

This would limit the ability to write, but you can't prohibit reading the filesystem I think. The VM needs to read the image for one thing. If the VM would allow FFI or OSProcess, would it be possible to limit application execution using container configuration? Because with FFI/OSProcess a (naughty) user could try to gain access to applications or data.

Hi Erik,

My VM is built on Alpine Linux. The official Alpine Linux Docker image is about 5MB. Adding the VM and plugins (including my own custom libsqlite3.so and some other shared libraries) gives a Docker image under 20MB. The size of your application - Smalltalk image, changes if required, other artefacts - is in your control of course.

Any pointers you can offer to a decent 'Dummies guide to Docker and containers' would be appreciated. I need the an equivalent to 'See container. See container run. Run, container, run!' sort of intro.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim The severity of the itch is proportional to the reach.

On Tue, 14 Apr 2020 at 10:43, tim Rowledge tim@rowledge.org wrote:

a) it's way past time we stopped opening a windows when it isn't needed. No window should be created until and unless the system actually writes to the display and calls for a display update. This would enable image-controlled headlessness. RISC OS was able to cope with it 25 years ago.

Pharo is doing that, in their branch https://github.com/pharo-project/opensmalltalk-vm/tree/headless which IIUC is the branch being used to build all Pharo VM going forward. Once they've worked the bugs out of it, it might be worth pulling that back to evaluate for Squeak to use.

cheers -ben

It’s Right in the middle! Klaarrung?

Sent from ProtonMail Mobile

On Wed, Apr 29, 2020 at 14:36, Robert robert.withers@pm.me wrote:

Are you saying that I can can run my 64-bit Squeak.image running PTAPAS [1] on the Pharo headless VM?!?!?! Now that, my Ladies and Gentlemen, would constitute a profound shout-out to the Heritage [2]. Hey, goddammit, don’t you forget your Heritage!!! You gained a profound VM for Pharo [3]! Do you feel me?

[1] PTAPAS - https://squeak.slack.com/archives/C02LC8AMS/p1587255601170900 [2] Squeak - https://Squeak.org [3] Cog Spur 64-bit Sista Multi, Malto, hi to hair, dost PI wisson calculiert, Schnell, Vielen Schnell!!!

Vas ist deinem mackht Los Corison Stein, meinen Schatchzie? Do you feel me, now?

^,^

Sent from ProtonMail Mobile

On Wed, Apr 29, 2020 at 13:57, Ben Coman btc@openinworld.com wrote:

...

On Tue, 14 Apr 2020 at 10:43, tim Rowledge tim@rowledge.org wrote:

...

a) it's way past time we stopped opening a windows when it isn't needed. No window should be created until and unless the system actually writes to the display and calls for a display update. This would enable image-controlled headlessness. RISC OS was able to cope with it 25 years ago.

Pharo is doing that, in their branch https://github.com/pharo-project/opensmalltalk-vm/tree/headless which IIUC is the branch being used to build all Pharo VM going forward. Once they've worked the bugs out of it, it might be worth pulling that back to evaluate for Squeak to use.

cheers -ben