[Rpcemu] (no subject)

Peter Howkins rpcemu.howkins at marutan.net
Wed May 13 13:59:27 PDT 2020

On Wed, 13 May 2020 at 21:02, <dfeugey at ascinfo.fr> wrote:

> Le 2020-05-13 20:31, Peter Howkins a écrit :
> > For the very same reason a webpage running javascript can't execute
> > shell commands or host API calls on your host OS.
> >
> Not the same. A web browser is a door opened to the outside. Local
> applications can do bad things, but inside the limits of the the rights
> and ACL you give to them.
I disagree with you. See below for more details.

> > Can you explain your use case here, what are you actually trying to
> > achieve?
> >
> - Universal print bridge from one only RISC OS PS driver

Are you planning on writing one?

> - USB auto-mounting in new hostfs drives

I'm not yet sure if multiple host mount points is not also a security
issue, as such automounters are not on my todo list right now.

> - SANE interface in a module

I don't know what you mean by SANE?

https://en.wikipedia.org/wiki/Scanner_Access_Now_Easy ?

If so, use that app on your Host OS

> - Local screen definition for dynamic screen resize

This might be interesting, Virtual Box, for example, allows you to resize
the Host OS window, and the information is passed onto the emulated OS to

Of course that doesn't require host OS integration, just the rpcemu
application to listen on the resize window event.

> - x86 (sandboxed) code (for speed)

Or just run the code on your Host OS.

> - Launch selected local applications (MP3 playing, etc.)

Just launch them on your Host OS

> - Local engines (for example x86 V8 mapped as a module, or BBCBasic x86
> as a module)

use a browser or BBCBasic x86 on your Host OS

> - Redirection of Qemu's Spice output in RISC OS Windows

... Host OS

> - SQL bridge

... Host OS

> Etc.


It seems as if a large number of these suggestions are "It would be better
if I could pretend the Host OS wasn't there". RPCEmu is about running RISC
OS and its applications on the Host, not running Host applications under
RISC OS, there's such a ludicrous amount of work there for so little
benefit that I'm not not interested in pursuing it.

Working around RISC OSs lack of applications in a system emulator of a 26
year old piece of hardware is pretty ridiculous.

> > It is entirely possible to provide access to host services in a secure
> > manner, if they have a defined scope.
> >
> Of course. I don't ask for some privilege escalation nightmare.

"run any command" or "Call any API" from another machine is the very
definition of a privilege escalation nightmare.

At the moment a RISC OS application can access anything in RISC OS at the
privilege level of the RISC OS user.

After your suggestion a RISC OS application can access anything in RISC OS
at the privilege level of the RISC OS user.*and *the RISC OS application
can also access anything in the Host OS at the privilege level of the Host
OS user that has run RPCEmu.

That's an enormous change in scope.

> <snip>
> If we can extend RPCEmu that way, you won't have to do it yourself. Else
> you can plan it too. It'll be even better :)

Note, I also have no interest in creating APIs that will allow closed
source extensions to RPCEmu. If you want to contribute to the project, by
all means do, but do so in the open.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.riscos.info/pipermail/rpcemu/attachments/20200513/43f676a1/attachment.html>

More information about the RPCEmu mailing list