in reply to chroot a directory...

If I've understood correctly, the problem is that someone could use the .. parent directory syntax to request a file/page outside of your $docroot ?

If so, then you may want to consider checking $path before opening the file. Use a regex to see if it contains .. preceded or followed by a / (there may be other possibilities, I haven't thought about it a great deal). If so, then deny the request.

One other security hole you should definitely close, is to use the 3-argument open():

open (FILE, '<', "$docroot$path")

Otherwise you are open to people crafting a request ending with | which could allow someone to run arbitrary code on your machine.

This is just a couple of things I thought of, there are probably other issues to be aware of as well...


s^^unp(;75N=&9I<V@`ack(u,^;s|\(.+\`|"$`$'\"$&\"\)"|ee;/m.+h/&&print$&

Replies are listed 'Best First'.
Re^2: chroot a directory...
by Anonymous Monk on Sep 09, 2004 at 16:34 UTC
    Well, if the OP goes with his plan to use chroot() instead of your suggestion, "the other" security hole isn't. There won't be executable available to run. chroot is a far better approach than "Use a regex to see if it contains .. preceded or followed by a / (there may be other possibilities, I haven't thought about it a great deal)." Not knowing whether there are other possibilities isn't exactly providing security.

      Fair enough about chroot... but there still isn't a reason to NOT use 3-arg open() - is there? Especially when the user input is untrusted.

      As per the OP's latest node, if they use:

      open (FILE, "$path")

      (rather than $docroot$path or whatever) then a client could request a $path of ">important.file" which could (depending on permissions) clobber the important file. Using the 3-arg open() suppresses the "special" interpretation of the first character.


      s^^unp(;75N=&9I<V@`ack(u,^;s|\(.+\`|"$`$'\"$&\"\)"|ee;/m.+h/&&print$&