RE: Orion on Linux NOT as root
This is very useful for me. Thanks for posting this ... Frank On Friday, September 29, 2000 3:43 AM, Jim Archer [SMTP:[EMAIL PROTECTED]] wrote: Thanks to all who replied. Acually, my original message was not too well written. I was not concerned about the port mapping issue. Thats not a big deal. We already have that issue with other processes, such as Apache, which runs as user nobody. Our issue is where to install Orion, what permissions each file should have, what user Orion should run as and so on. We would prefer Orion not run as root (we don't let Apache run as root either) and that its files not all be world writable by default (which is what happens when we unzip it onto our Debian system). Mostly, we need to know what directories Orion needs to write in, what ones it does not, which files it needs to edit and so on. Below is a note from the guy who has been working on this. He explaines our problem and the partial solution he worked up in detail: Jim, I figured out most of the pieces needed to do it, but we still have a problem. This all applies to Orion 1.3.8 running on Debian Linux 2.2 "Potato" with a 2.2.14 (patched) kernel and IBM JDK 1.3.0 build cx130-2815. 1. The main issue these people are discussing on the list is how to get the server to listen on port 80, which is not our issue. On Unix, only "root" can connect to ports below 1024. This is actually a trivial problem, since the solution is to have the Orion server listen on some other port, like 8080, and have a simple shim running as root that proxies port 80 to that other port. 2. What was causing us grief was exactly what I thought was causing us grief. The file structure is Windows-like, and it has to be shoehorned into a proper Unix structure. Basically, I split the Orion directory structure into a bunch of things that Orion itself should never have write permission for, which is now in /usr/local/share/orion and is owned by "root," and into a bunch of things that Orion itself does need write permission for, which is now in /var/local/orion and is mostly owned by the new "orion" user. It is necessary to edit the XML files in /usr/local/share/orion/config to account for this. What actually must be moved to /var/local/orion is only three directories: guardian:~$ ls -l /var/local/orion drwxr-sr-x3 orion orion4096 Jul 5 14:40 application-deployments drwxr-sr-x4 rootstaff4096 Sep 28 16:03 default-web-app drwxr-sr-x2 orion orion4096 Sep 28 03:44 log drwxr-sr-x3 orion orion4096 Jun 5 14:38 persistence I also moved "default-web-app" here, although only the "WEB-INF" directory below it needs to be writable to the server: guardian:~$ ls -l /var/local/orion/default-web-app/ drwxr-sr-x3 orion orion4096 Sep 28 16:11 WEB-INF drwxr-sr-x8 rootstaff4096 Jun 5 14:38 examples -rw-r--r--1 rootstaff2044 Sep 28 16:03 index.html (Note that the Orion server does not seem to handle CRLF end-of-line conventions, and I had to convert "index.html" to LF-only in order to get things working without errors. Of course, that is a very minor problem, but it explains why the timestamp on the file is recent.) In the "WEB-INF" directory, the "classes" subdirectory does not appear to need to be writable by the server: guardian:~$ ls -l /var/local/orion/default-web-app/WEB-INF/ drwxr-sr-x9 rootstaff4096 Jun 5 14:38 classes -rw---1 orion orion 386 Sep 28 15:37 web.xml 3. Now, this arrangement ALMOST works. The first time a particular JSP file is invoked the server tries to create directores below /var/local/orion/application-deployments/default/defaultWebApp/persistence/ examples/jsp such as "checkbox" for the checkbox example and "num" for the numberguess example, and then it tries to create x.jsp.jspCache files in these subdirectories (where "x" is the base name of the JSP file). This works only if the server is started by the "root" user, but not if the server is started by the "orion" user. Since the entire tree from /var/local/orion/application-deployments down is owned by the "orion" user who has full permissions, this makes no sense: guardian:~$ ls -l /var/local/orion/application-deployments/default/defaultWebApp/persistence/ examples/ drwx--4 orion orion4096 Sep 28 17:46 jsp Once the directory and the x.jsp.jspCache file have been created by invoking the JSP file the first time with the server started by the "root" user, ownership of this directory and its contents can be changed manually to the "orion" user and the server can then be started as the "orion" user. At that point, any JSP for which the appropriate x.jsp.jspCache file already exists will work. My guess is that the server is somehow trying to drop privilege or otherwise change its euid when it does whatever it does to build the
Re: Orion on Linux NOT as root
Buried under debug tips is a list of Orion startup options. Take a look under properties (about halfway down the page at http://www.orionserver.com/howtos/debug-tips.html , where you'll find "native.user Used to run Orion under another user than root for unix systems" I remember this being mentioned on the mail list before, so perhaps there's some details in the archives. I haven't tried it, yet... If it works I recommend that you make a separate orion user and group, and you might want to run it chroot'd also. If Orion's successful enough the script kiddies sigh/ will start publishing exploits. Kirk Yarina At 09:42 PM 9/28/00 -0400, you wrote: Thanks to all who replied. Acually, my original message was not too well written. I was not concerned about the port mapping issue. Thats not a big deal. We already have that issue with other processes, such as Apache, which runs as user nobody. Our issue is where to install Orion, what permissions each file should have, what user Orion should run as and so on. We would prefer Orion not run as root (we don't let Apache run as root either) and that its files not all be world writable by default (which is what happens when we unzip it onto our Debian system). Mostly, we need to know what directories Orion needs to write in, what ones it does not, which files it needs to edit and so on. Below is a note from the guy who has been working on this. He explaines our problem and the partial solution he worked up in detail: Jim, I figured out most of the pieces needed to do it, but we still have a problem. snip Kirk Yarina [EMAIL PROTECTED]
Re: Orion on Linux NOT as root
If you're OS has support for it you can set up packet filtering (aka firewalling) rules that forward packets going to the privileged port 80 to some unprivileged port, for example 8000. Then just make Orion listen on that unprivileged port. Works like a charm for me. In Linux's case I guess ipchains would be used. I can only provide instructions for FreeBSD. Markus On Thu, Sep 28, 2000 at 04:38:12PM -0400, Jim Archer wrote: Hi All... We have been developing under Orion on Windows machines, but the time came last night to start testing on Linux, our intended server platform. We installed 1.3.8 on Debian Linux and quickly discovered that it wants to run as root. We really can't allow this. I went through the list archive and saw a discussion about this issue from last April, but didn't see what the resolution was (if any). Is there now a way to run Orion on Linux not as root (ideally as user nobody) and, if so, is there any doc on this? Thanks... Jim -- Markus Holmberg | Give me Unix or give me a typewriter. [EMAIL PROTECTED] | http://www.freebsd.org/
Re: Orion on Linux NOT as root
We spent a lot of time on this too. OrionSupport.com if it comes back had a way to do it through JNDI. We've ended up doing through having a Cisco Local Director mapping ports 80 and 443 to 8080 and 8081 If you don't have the budget for a local director, you could emulate that function with a Linux box and IP-Chains, or probably an off the shelf firewall. -Lkb At 04:38 PM 9/28/00 -0400, Jim Archer wrote: Hi All... We have been developing under Orion on Windows machines, but the time came last night to start testing on Linux, our intended server platform. We installed 1.3.8 on Debian Linux and quickly discovered that it wants to run as root. We really can't allow this. I went through the list archive and saw a discussion about this issue from last April, but didn't see what the resolution was (if any). Is there now a way to run Orion on Linux not as root (ideally as user nobody) and, if so, is there any doc on this? Thanks... Jim /** * @author: Lorin Kobashigawa-Bates [EMAIL PROTECTED] * @title: CodeMonkey / COO - Robot6 Inc. * @phone: 415.345.8872 * @addr: 1177 Polk St. San Francisco, CA 94109 */
Re: Orion on Linux NOT as root
You can run Orion as a native user using some native code that is available somewher.e Unfortunatly, information on how this was done used to be on www.orionsupport.com which appears to be down. There is some info in this e-mail: http://www.mail-archive.com/orion-interest@orionserver.com/msg01696.html But I don't know where to get the native library any more. Orion team? - Original Message - From: "Markus Holmberg" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Thursday, September 28, 2000 4:46 PM Subject: Re: Orion on Linux NOT as root If you're OS has support for it you can set up packet filtering (aka firewalling) rules that forward packets going to the privileged port 80 to some unprivileged port, for example 8000. Then just make Orion listen on that unprivileged port. Works like a charm for me. In Linux's case I guess ipchains would be used. I can only provide instructions for FreeBSD. Markus On Thu, Sep 28, 2000 at 04:38:12PM -0400, Jim Archer wrote: Hi All... We have been developing under Orion on Windows machines, but the time came last night to start testing on Linux, our intended server platform. We installed 1.3.8 on Debian Linux and quickly discovered that it wants to run as root. We really can't allow this. I went through the list archive and saw a discussion about this issue from last April, but didn't see what the resolution was (if any). Is there now a way to run Orion on Linux not as root (ideally as user nobody) and, if so, is there any doc on this? Thanks... Jim -- Markus Holmberg | Give me Unix or give me a typewriter. [EMAIL PROTECTED] | http://www.freebsd.org/
RE: Orion on Linux NOT as root
You could've used ipfilter for Solaris -Original Message- From: Sach Jobb [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 28, 2000 5:43 PM To: Orion-Interest Subject: Re: Orion on Linux NOT as root We just went through this about a week ago, check out the list archives. There are a number of work arounds, since you are using linux you can use ipchains built in port forwarding to redirect port 80 to some other non privilaged port (say 8080) and then start orion as a normal user. In my situation we weren't using linux (solaris), so we through money at it... that always works. ;) We ended up using a cisco local director to handle the port forwarding for us. I'd also check the new documentation, we've discovered all kinds of _really_ interesting things in there today. sach %s/windows/linux/g On Thu, 28 Sep 2000, Jim Archer wrote: Hi All... We have been developing under Orion on Windows machines, but the time came last night to start testing on Linux, our intended server platform. We installed 1.3.8 on Debian Linux and quickly discovered that it wants to run as root. We really can't allow this. I went through the list archive and saw a discussion about this issue from last April, but didn't see what the resolution was (if any). Is there now a way to run Orion on Linux not as root (ideally as user nobody) and, if so, is there any doc on this? Thanks... Jim
Re: Orion on Linux NOT as root
Thanks to all who replied. Acually, my original message was not too well written. I was not concerned about the port mapping issue. Thats not a big deal. We already have that issue with other processes, such as Apache, which runs as user nobody. Our issue is where to install Orion, what permissions each file should have, what user Orion should run as and so on. We would prefer Orion not run as root (we don't let Apache run as root either) and that its files not all be world writable by default (which is what happens when we unzip it onto our Debian system). Mostly, we need to know what directories Orion needs to write in, what ones it does not, which files it needs to edit and so on. Below is a note from the guy who has been working on this. He explaines our problem and the partial solution he worked up in detail: Jim, I figured out most of the pieces needed to do it, but we still have a problem. This all applies to Orion 1.3.8 running on Debian Linux 2.2 "Potato" with a 2.2.14 (patched) kernel and IBM JDK 1.3.0 build cx130-2815. 1. The main issue these people are discussing on the list is how to get the server to listen on port 80, which is not our issue. On Unix, only "root" can connect to ports below 1024. This is actually a trivial problem, since the solution is to have the Orion server listen on some other port, like 8080, and have a simple shim running as root that proxies port 80 to that other port. 2. What was causing us grief was exactly what I thought was causing us grief. The file structure is Windows-like, and it has to be shoehorned into a proper Unix structure. Basically, I split the Orion directory structure into a bunch of things that Orion itself should never have write permission for, which is now in /usr/local/share/orion and is owned by "root," and into a bunch of things that Orion itself does need write permission for, which is now in /var/local/orion and is mostly owned by the new "orion" user. It is necessary to edit the XML files in /usr/local/share/orion/config to account for this. What actually must be moved to /var/local/orion is only three directories: guardian:~$ ls -l /var/local/orion drwxr-sr-x3 orion orion4096 Jul 5 14:40 application-deployments drwxr-sr-x4 rootstaff4096 Sep 28 16:03 default-web-app drwxr-sr-x2 orion orion4096 Sep 28 03:44 log drwxr-sr-x3 orion orion4096 Jun 5 14:38 persistence I also moved "default-web-app" here, although only the "WEB-INF" directory below it needs to be writable to the server: guardian:~$ ls -l /var/local/orion/default-web-app/ drwxr-sr-x3 orion orion4096 Sep 28 16:11 WEB-INF drwxr-sr-x8 rootstaff4096 Jun 5 14:38 examples -rw-r--r--1 rootstaff2044 Sep 28 16:03 index.html (Note that the Orion server does not seem to handle CRLF end-of-line conventions, and I had to convert "index.html" to LF-only in order to get things working without errors. Of course, that is a very minor problem, but it explains why the timestamp on the file is recent.) In the "WEB-INF" directory, the "classes" subdirectory does not appear to need to be writable by the server: guardian:~$ ls -l /var/local/orion/default-web-app/WEB-INF/ drwxr-sr-x9 rootstaff4096 Jun 5 14:38 classes -rw---1 orion orion 386 Sep 28 15:37 web.xml 3. Now, this arrangement ALMOST works. The first time a particular JSP file is invoked the server tries to create directores below /var/local/orion/application-deployments/default/defaultWebApp/persistence/ examples/jsp such as "checkbox" for the checkbox example and "num" for the numberguess example, and then it tries to create x.jsp.jspCache files in these subdirectories (where "x" is the base name of the JSP file). This works only if the server is started by the "root" user, but not if the server is started by the "orion" user. Since the entire tree from /var/local/orion/application-deployments down is owned by the "orion" user who has full permissions, this makes no sense: guardian:~$ ls -l /var/local/orion/application-deployments/default/defaultWebApp/persistence/ examples/ drwx--4 orion orion4096 Sep 28 17:46 jsp Once the directory and the x.jsp.jspCache file have been created by invoking the JSP file the first time with the server started by the "root" user, ownership of this directory and its contents can be changed manually to the "orion" user and the server can then be started as the "orion" user. At that point, any JSP for which the appropriate x.jsp.jspCache file already exists will work. My guess is that the server is somehow trying to drop privilege or otherwise change its euid when it does whatever it does to build the x.jsp.jspCache files. When this fails, we get an error message (in the browser from which the JSP invocation was attempted) like this: 500 Internal Server Error Error parsing JSP page /examples/jsp/dates/date.jsp IO Error:
