Hy again! (Sorry for bothering again.)
I think I've stumbled upon another oddity: when configuring the
server correctly (by setting the `chroot` folder, and all other paths
as absolute ones), and starting mongrel from inside the (to be)
chrooted folder, but without the `-sudo` option it works Ok. But when
starting the server (again without the `-sudo`) from inside another
folder, it seems that at first it tries to use the concatenated chroot
+ pid_file path, but when creating it, it only looks for the pid_file
path relative to the current working directory. (Which would make
sense assuming the `chroot` succeeded.)
Shouldn't Mongrel always try to at least `chdir` to the chroot
folder regardless if it has succeeded in chrooting or not? (This would
solve the inconsistency I've described earlier.)
I've also found another peculiarity: by mistake at beginning I've
used all paths as relative ones, e.g. access_log = './access.log', and
when running, mongrel actually used the path `../access_log`, because
I think internally you concatenate the path with a `.` Shouldn't you
require that all paths be written as absolute ones (with no `.` or
`..` as elements)?
For actual details, I've tried the following (the `~~~~` only
delimit snippets of commands).
Thanks again,
Ciprian.
~~~~
mkdir /tmp/mongrel-test-1
cd /tmp/mongrel-test-1
mkdir ./run ./log ./tmp ./www
~~~~
cat <<EOS >./mongrel2.conf
main = Server (
name = 'tests',
uuid = 'f400bf85-4538-4f7a-8908-67e313d515c2',
port = 8080,
access_log = '/log/access.log',
error_log = '/log/error.log',
pid_file = '/run/mongrel2.pid',
chroot = '/tmp/mongrel-test-1',
default_host = '127.0.0.1',
hosts = [
Host (
name = '127.0.0.1',
routes = {
'/': Dir (base = 'www/', index_file = 'index.txt',
default_ctype = 'text/plain')
})
]
)
servers = [main]
EOS
~~~~
m2sh load
~~~~
So now let's start it:
~~~~
# we go to where it should chroot, but we don't as we don't have root
priviledges
cd /tmp/mongrel-test-1
m2sh start -name tests
# everything works Ok.
~~~~
But when I try:
~~~~
# we go outside where it should chroot
cd /tmp
m2sh start -name tests -db /tmp/mongrel-test-1/config.sqlite
# ...
[ERROR] (src/unixy.c:99: errno: No such file or directory) Failed to
open PID file /tmp/mongrel-test-1/run/mongrel2.pid for reading.
...
[ERROR] (src/unixy.c:55: errno: Operation not permitted) Can't chroot
to /tmp/mongrel-test-1, rerun as root if this is what you want.
[ERROR] (src/mongrel2.c:188: errno: None) Couldn't chroot too
/tmp/mongrel-test-1, assuming running in test mode.
[ERROR] (src/unixy.c:166: errno: No such file or directory) Failed to
open PID file ./run/mongrel2.pid for writing.
[ERROR] (src/mongrel2.c:200: errno: None) Failed to make the PID file
./run/mongrel2.pid
[ERROR] (src/mongrel2.c:292: errno: None) Major failure in
chroot/droppriv, aborting.
[ERROR] (src/mongrel2.c:321: errno: None) Exiting due to error.
~~~~
Now let's try (just to be sure):
~~~~
# we go outside where it should chroot
cd /tmp
sudo m2sh start -name tests -sudo -db /tmp/mongrel-test-1/config.sqlite
# again everything works ok.
killall mongrel2
~~~~
On Thu, Nov 04, 2010 at 10:40:39PM +0200, Ciprian Dorin, Craciun wrote: > Hy again! (Sorry for bothering again.) > > I think I've stumbled upon another oddity: when configuring the > server correctly (by setting the `chroot` folder, and all other paths No, the thing about non-root startup is it's either done by a developer and they're in the directory they want to work with, or it's done by some external process manager like daemontools or procer which does the cd/chroot stuff for mongrel2. In fact I think users of these tools were very adamant that it *not* do jack squat since they want to do all that stuff. Toss in another ticket and I'll look at if there's a way to resolve it. Otherwise, just run it from that directory. -- Zed A. Shaw http://zedshaw.com/
On Fri, Nov 5, 2010 at 02:03, Zed A. Shaw <zedshaw@zedshaw.com> wrote: > On Thu, Nov 04, 2010 at 10:40:39PM +0200, Ciprian Dorin, Craciun wrote: >> Hy again! (Sorry for bothering again.) >> >> I think I've stumbled upon another oddity: when configuring the >> server correctly (by setting the `chroot` folder, and all other paths > > No, the thing about non-root startup is it's either done by a developer > and they're in the directory they want to work with, or it's done by > some external process manager like daemontools or procer which does the > cd/chroot stuff for mongrel2. In fact I think users of these tools were > very adamant that it *not* do jack squat since they want to do all that > stuff. > > Toss in another ticket and I'll look at if there's a way to resolve it. > Otherwise, just run it from that directory. > > -- > Zed A. Shaw > http://zedshaw.com/ After reading the entire manual (I didn't go to sleep until I've finished it :) ) I think you are right about your approach. It's almost impossible to do the right thing in both the chrooting and non-chrooting cases. (So indeed `chdir`-ing doesn't make much sense in case I'm using runit (which I am :) ) and the like.) But, I think there is one thing that can be done to at least stop users to shooting their feet: when loading the config, the `m2sh` tool should enforce that the paths (`access_log`, `pid_file`, etc.) don't start with any `./`, `../`, or `/`, but are just plain relative paths (like `run/mongrel2.pid`). (This is done for the `Dir` option where I'm not allowed to start with a `/`.) And then when concatenating them with the `chroot` just also throw a `/` between them. (For now if any path starts with `./` I get the weird behaviour I've described in the previous mail, or if I don't start them with `/` I get a similar weird behaviour.) And another thing -- I've looked through the code, after receiving errors about missing `/tmp` folder when running mongrel2 by hand as root -- It seems that in the file `./src/mongrel2` there are the following two lines (169-170): ~~~~ check(access("/run", F_OK) == 0, "/run directory doesn't exist in %s or isn't owned right.", bdata(srv->chroot)); check(access("/tmp", F_OK) == 0, "/tmp directory doesn't exist in %s or isn't owned right.", bdata(srv->chroot)); ~~~~ Should these paths be hardcoded here? I know that they are sanity checks, but shouldn't they actually check the prefix of the `srv->pid_file`, `srv->access_log`, etc? (And what is even stranger is that I don't get the error for the `/run` folder even though I don't have it, but it gives me the error for the /tmp Thanks, Ciprian.