Menu
▾
▴
Re: [Oorexx-devel] Only root can allow ooRexx to run on Linux ? (Re: Fwd: [ oorexx-Bugs-2796185 ] REX121: Storage for data queues is exhausted (on MacOSX)
|
From: René J. <rvj...@xs...> - 2009-07-13 21:28:12
|
Hi Mark, well, this is not practice. Plain users on all kind of machines install all kinds of tools to run out of their home directories every day, where a root install requires a root password from some security desk, most of the time linked to a change request or an incident number. Then again, these machines are generally not called PC's but lpars or virtual machines. I would like to go into the specific of this root requirement a bit more. It is processes running as root that attract attention, and this is what I would want to avoid. Audit deparments are fine with user mode software running to perform utility tasks. I also would like to compare some of the competitive products (python, ruby) against such a requirement. If it was only an install time requirement it is not a big problem. The fear is here of course that rxapi can be subverted or has buffer overrun possibilities to execute arbotrary code as root. If the process can run as 'nobody' it will be accepted like an httpd is accepted. By the way, we are not forcing people to install in /usr/bin or anywhere else the system should be the owner (or the filesystem being readonly as it is shared, like in some zLinux installations). On Mac there is a script providing symbolic links, but the product will also run out of /opt/ with the right path and LD_LIBRARY_PATH. In fact, and let me make a note of it, we should be able to run the whole installer without requiring root. What I am interested in is the technical requirement for the rxapi process to run in root (more than writing on a pid file in a restricted area). Is it necessary to share data in queues this way? Is there one on HP/UX? AIX? zLinux? For MacOSX I don't see it yet (but some testing might prove otherwise, I admit) best regards, René Jansen. On 13 jul 2009, at 16:14, Mark Miesfeld wrote: > Well, when I saw the start of this thread, I was going to make the > following point. But, I see David already touched on it. > Nevertheless, I'm going to repeat it. > > Besides any technical reasons, this is an ethical problem. If you can > not get root privileges on a PC, then the computer does not belong to > you. If the computer does not belong to you, then, ethically, you > need the permission of the owner of the computer to install any > software on that computer. > > So, either the owner of the computer will give you permission to > install it and help get it installed using whatever mechanism is in > place. Or, the owner of the computer will not give you permission. > In which case, ethically and morally you shouldn't install the > software to begin with. > > -- > Mark Miesfeld > > On Mon, Jul 13, 2009 at 6:46 AM, David Ashley<dav...@gm... > > wrote: >> All - >> >> Having rxapi run as a system daemon is an absolute necessity on *nix >> systems. This is the only way to get reliable and secure >> communications >> between processes without needless overhead. >> >> The old shared memory communications mechanism was a disaster >> waiting to >> happen. Not only was it CPU intensive but it left security holes a >> mile >> wide. It is not a good idea to have one user process service requests >> for another user process. That is a security violation of the highest >> order and that is exactly what happened in that model. With the root >> user processing all user requests we at least get the chance to >> reject a >> request that might violate some security rule. Currently we don't >> have >> requests like that available but at least with a root daemon >> processing >> all requests we get the chance to implement that kind of mechanism in >> the future. >> >> Now one last point. To install ooRexx at all as system provided >> software >> you have to install the binaries in protected locations like /usr/bin >> and /usr/lib. You typically need root permission to do this for very >> good security reasons. Thus installing rxapi as a root/system >> daemon is >> no big deal under those restrictions. Trying to install ooRexx as >> single >> user software is not a good idea for a number of reasons but the >> point >> is that if you are not allowed to perform a system installation of >> ooRexx on a machine then there is probably a security policy in place >> that would not allow you to install ooRexx as user software as >> well. In >> every customer account I have dealt with these policies are joined at >> the hip. If you can't install system software you will also not be >> allowed to install user software. >> >> Security cannot be looked at from a single policy perspective. You >> have >> to step back and consider the big picture and the impacts of all >> decisions. This is very hard for people used to dealing with Windows >> which no matter what Microsoft claims is a single user system. >> Multi-user system are a far different animal and security policies >> that >> make sense in one environment can be either useless or a disaster in >> another environment. >> >> The only way for ooRexx to gain acceptance in the larger user >> community >> is to ensure that it gets installed and made available by default >> on as >> many systems as possible. We simply cannot do that without the *nix >> distributors help. Just making ooRexx available to individual users >> in >> that environment is not a strategy that will increase our market >> share. >> Making sure we have a secure, reliable and advantageous interpreter >> will >> get us the notice we need from distributors, administrators and >> programmers and that will ensure our success. >> >> 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 |