On Wed, 13 May 2020 at 21:02, <dfeu...@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 resize. 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. > 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. Peter
_______________________________________________ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
