Menu
▾
▴
Re: [Oorexx-devel] Running rxapi as a non root user on Linux
|
From: René J. <rvj...@xs...> - 2009-07-15 15:20:48
|
I think switching to a non-root user is good. It is also unnecessary if the process is already started as non-root. The reason for starting it as root is, as far as I know now, only to write the pid file on a portion of the filesystem that is not writeble by non-root. If the pid file ony exists for the script, then still the disadvantage of having to install a launchd script to start as root, or the impossibility of running from USB or live cd outweigh the advantage of having the script around. Remember, the existence of a pid file does not imply the existence of a process. I have a lot of experience running PostgreSQL and one of its nuisances is having to su - root or sudo to remove the pid file from a defunct process. In my view ps -ef grep | rxapi is a more surefire way of viewing and killing a process. I still do not see any compelling reason to run as root - and the process owner switch would require root, so the reason to be root would be in order not to run as root. I have no problem in running this differently on MacOSX but I'd rather we could agree the same way for all Unices. Our customer account is going to do a proof of concept with z/Linux - hence my compiling of the daylies for z/Arch in 64 bit. How cool would it be to have ooRexx be able to run in user mode, and just start up rxapi when needed, on a system or user scope. Or to have a stick and be able to run on anyones Windows machines instead of resorting to the dreaded .bat language while performing our duty for family and friends, or even doing something useful at work while winning over souls for ooRexx. Which brings me to the question if the test suite has tests in it that hammer the rxapi process from different user processes at the same time, because that is what is going to happen eventually. It also brings me to the question how this worked in previous versions. I know that Linux and Mac did System V shared memory, and I remember a lot of traffic on the rxapi and the installer on Windows. Was this absent on Linux? I know I did not put in into the installer for Mac, so unless it started it up itself it did not run. best regards, René Jansen. On 15 jul 2009, at 16:00, David Ashley wrote: > There are two pieces to the rxapi story. First there is the rxapi > binary. Second, there is the rxapid shell script. > > The rxapid shell script is the traffic cop for the rxapi binary. The > shell script starts, stops and produces status info via the RH > service command. To status and stop the binary it reads the pid file > and determines if the process is still running. So the rxapi binary > must write out the pid file for that to happen. > > In order to get the pid file written the rxapi binary must be > running as root (the default when it is started from the shell > script). To change the ownership of the process to a non-root user > you make some api calls just after you write the pid file and before > you begin processing user requests. That way no user request can > generate any problems that would violate the security of the system. > > If the rxapi binary is owned and running with root privileges then a > buffer overrun attack could damage the system or some other attack > might be possible. By changing the process owner to a non-root user > you eliminate that possibility. > > David Ashley > > On 07/15/2009 08:32 AM, Rick McGuire wrote: >> >> Does this still mean that write authority for the pid file is still >> required? Eliminating the root privileges is a good thing, but it >> won't allow the USB stick version unless you can start rxapi as root. >> >> I'm not really sure I understand what that particular file is used >> for. >> >> Rick >> >> On Wed, Jul 15, 2009 at 9:26 AM, David Ashley<dav...@gm... >> > wrote: >> >>> Ok, some clarification. I am NOT talking about making the install >>> available >>> to a non-root user. I am only speaking to running rxapi as a non- >>> root user. >>> The install will still need to be performed by root. >>> >>> What will happen is that just after rxapi writes to the pid file >>> code will >>> be added that changes to process owner to "nobody". This will >>> eliminate root >>> privileges for the process and thus make it more attractive to the >>> security >>> paranoid. >>> >>> The only change will be to add about 5 lines of code to the rxapi >>> startup >>> functions. >>> >>> David Ashley >>> >>> On 07/14/2009 06:19 PM, Rick McGuire wrote: >>> >>> How about a compromise? We make the code changes to enable rxapi to >>> run as a normal process, but keep the install procedures the same >>> for >>> now. The code is already in place to auto-launch rxapi if it is not >>> running, but currently this only works if you're running as root. >>> If >>> we can eliminate that requirement, then there is a lot more >>> flexibility in how things get configured, and we probably don't need >>> to make any patches to the code to support the Mac, >>> >>> Rick >>> >>> On Tue, Jul 14, 2009 at 7:13 PM, Mark Miesfeld<mie...@gm...> >>> wrote: >>> >>> >>> On Tue, Jul 14, 2009 at 4:03 PM, David Ashley<dav...@gm... >>> > >>> wrote: >>> >>> >>> >>> Ok, I'm convinced. rxapi does not need to run as the root user on >>> *nix >>> systems. It has nothing it needs to do which would require root >>> privileges. >>> >>> So the question becomes should we implement this change prior to the >>> release of 4.0 or wait until the next release? >>> >>> >>> I am not in favor of making a change now, well actually I'm >>> against it. >>> >>> I am in favor of having an install that doesn't require su to root >>> to >>> install, but I think we should get this release out of the door and >>> plan on doing a follow up release in 3 months to fix bugs I know >>> will >>> be reported and straighten out details like this one. >>> >>> As far as I can see, the current 3.2.0 Linux rpms and debs can not >>> be >>> installed unless you su to root. So what's the problem? There >>> hasn't >>> been a single user complaint about this in 2 years. >>> >>> In the current 4.0.0, you have to su to root to install the rpm or >>> to >>> install the deb. After that there is no problem. This situation is >>> no different than it has been. >>> >>> -- >>> Mark Miesfeld >>> >>> >>> The code changes are >>> >>> >>> small but the testing could be a problem (although I do not expect >>> any). >>> >>> Opinions welcome. >>> >>> David Ashley >>> >>> ------------------------------------------------------------------------------ >>> Enter the BlackBerry Developer Challenge >>> This is your chance to win up to $100,000 in prizes! For a limited >>> time, >>> vendors submitting new applications to BlackBerry App World(TM) >>> will have >>> the opportunity to enter the BlackBerry Developer Challenge. See >>> full prize >>> details at: http://p.sf.net/sfu/Challenge >>> _______________________________________________ >>> Oorexx-devel mailing list >>> Oor...@li... >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Enter the BlackBerry Developer Challenge >>> This is your chance to win up to $100,000 in prizes! For a limited >>> time, >>> vendors submitting new applications to BlackBerry App World(TM) >>> will have >>> the opportunity to enter the BlackBerry Developer Challenge. See >>> full prize >>> details at: http://p.sf.net/sfu/Challenge >>> _______________________________________________ >>> Oorexx-devel mailing list >>> Oor...@li... >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Enter the BlackBerry Developer Challenge >>> This is your chance to win up to $100,000 in prizes! For a limited >>> time, >>> vendors submitting new applications to BlackBerry App World(TM) >>> will have >>> the opportunity to enter the BlackBerry Developer Challenge. See >>> full prize >>> details at: http://p.sf.net/sfu/Challenge >>> _______________________________________________ >>> Oorexx-devel mailing list >>> Oor...@li... >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Enter the BlackBerry Developer Challenge >>> This is your chance to win up to $100,000 in prizes! For a limited >>> time, >>> vendors submitting new applications to BlackBerry App World(TM) >>> will have >>> the opportunity to enter the BlackBerry Developer Challenge. See >>> full prize >>> details at: http://p.sf.net/sfu/Challenge >>> _______________________________________________ >>> Oorexx-devel mailing list >>> Oor...@li... >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> >>> >>> >> >> ------------------------------------------------------------------------------ >> Enter the BlackBerry Developer Challenge >> This is your chance to win up to $100,000 in prizes! For a limited >> time, >> vendors submitting new applications to BlackBerry App World(TM) >> will have >> the opportunity to enter the BlackBerry Developer Challenge. See >> full prize >> details at: http://p.sf.net/sfu/Challenge >> _______________________________________________ >> Oorexx-devel mailing list >> Oor...@li... >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >> > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited > time, > vendors submitting new applications to BlackBerry App World(TM) will > have > the opportunity to enter the BlackBerry Developer Challenge. See > full prize > details at: http://p.sf.net/sfu/Challenge_______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel |