Grrr, didn't get to the undo button in time...
On Wed, Nov 21, 2018 at 9:07 AM Rick McGuire <[email protected]> wrote: > I have started doing a little research on this, and I see how to implement > this on Windows, but I'm not sure the existing client/server set up will > work with *ix named pipes. The rxapi process handles requests like this: > > Main thread binds to a port > do forever > Main thread listens for an inbound connection, which will be a new process > where rexx is being used. > A new thread is created to handle requests from this session, terminating > once the client process terminates. > end On Windows, a server can have multiple active named pipe connections using a common name. It does not appear that Linux has that capability. I have seen some references to using AF_LOCAL (or AF_UNIX) sockets which bind using a service name, which looks like a fairly easy replacement for what we currently have. Windows, sadly, does not have AF_UNIX support except in some updates of Windows 10, but the named pipe solution can be abstracted to behave the same way. Unless I'm missing something, how did you envision doing this with named pipes? Links to relevant docs greatly appreciated! Rick > > > On Fri, Mar 30, 2018 at 2:10 PM Moritz Hoffmann <[email protected]> > wrote: > >> The pipes-based version has one rxapi deamon per user. In fact, the pipe >> file is owned and only accessible by the user that spawned the rxapi >> daemon. That means another user has no way of accessing the pipe. I should >> have some time tomorrow so I can see how much work it is for *nix, but I'd >> need someone else to look at the Windows part (although the Windows doc >> seems to be quite clear about named pipes, just have to get my development >> environment up.) >> >> Moritz >> >> On Fri, Mar 30, 2018 at 6:47 PM, Rick McGuire <[email protected]> >> wrote: >> >>> Does the pipes-based version have real user isolation? In other words, >>> do you end up with one process per user? That would be a very good thing if >>> we can get the real isolation. However, I think I share your opinion about >>> trying to rush a replacement into 5.0.0. Historically, the rxapi daemon has >>> been the source of a lot of problems whenever things have changed, so any >>> replacement should get a lot of use and exposure before doing a roll out. >>> >>> Rick >>> >>> On Fri, Mar 30, 2018 at 12:40 PM, Moritz Hoffmann <[email protected]> >>> wrote: >>> >>>> Hi, >>>> yes, I was playing around with supporting pipes as another means of >>>> binding to the rxapi daemon. It was a rather simple change, the main effort >>>> was in extending/changing the communication abstraction classes not to >>>> assume they were socket-based. I had it running on Linux and I assume the >>>> same functionality would be available on MacOS, but I've no experience on >>>> how to use pipes in Windows. Quite sure they exist though! >>>> >>>> I'm not too sure we should include it in the 5.0.0 release. Firstly, it >>>> will require some testing and I'm sure it will have bugs at the beginning, >>>> just due to the fact that the pipe file needs to be stored somewhere and >>>> that might be different depending on the Linux distribution. Secondly, the >>>> rxapi daemon works fine at the moment. >>>> >>>> The only problem I see with the rxapi daemon is that it does not >>>> provide any isolation of users on the same host. The user id is passed as >>>> data in the messages so it's easy to patch ooRexx to use a different id >>>> instead. I guess we could call it a known and currently accepted >>>> vulnerability. Anyone who can connect to localhost can access the shared >>>> api daemon. >>>> >>>> If there's interest I could spin up the pipes-based version. Should >>>> take too long, just let me know. >>>> >>>> Moritz >>>> >>>> On Fri, Mar 30, 2018 at 5:02 PM, René Jansen <[email protected]> >>>> wrote: >>>> >>>>> Moritz, >>>>> >>>>> After Gil’s talk I am also excited about ADDRESS WITH (and the fact >>>>> that it has been taken up by Rick) so we might hold off the freeze for >>>>> some >>>>> time until we have all infrastructure and installers ready (and maybe have >>>>> ADDRESS WITH). Maybe this gives us also time to look into the portable >>>>> version again. I personally think this would be a great boost for takeup. >>>>> >>>>> I remember you had a set of patches to turn the sockets of rxapi into >>>>> pipes. I do not remember if this was windows-only or also included >>>>> linux/macos. >>>>> >>>>> The issues with rxapi: >>>>> >>>>> - you must be authorized to run it on its port >>>>> - the firewall must allow access (cost me great headaches on Z, where >>>>> the standard image for a Linux VM was very restrictive, and you got a >>>>> timeout and no message) >>>>> - you must be authorized to start it, so that means a service on >>>>> windows or some systemd / startup item >>>>> - it writes a PID file so whoever starts it, must be authorized to >>>>> write there >>>>> >>>>> Thing is, solutions must work for the three main platforms, that is >>>>> the reason of my question. >>>>> >>>>> best regards, >>>>> >>>>> >>>>> René >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Check out the vibrant tech community on one of the world's most >>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>>> _______________________________________________ >>>>> Oorexx-devel mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>>>> >>>> >>>> >>>> >>>> -- >>>> Moritz Hoffmann; >>>> http://antiguru.de/ >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> Oorexx-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Oorexx-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> >>> >> >> >> -- >> Moritz Hoffmann; >> http://antiguru.de/ >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Oorexx-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >
_______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
