Re^2: chroot a directory...

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.

Comment on Re^2: chroot a directory...

Replies are listed 'Best First'.
Re^3: chroot a directory... by muntfish (Chaplain) on Sep 10, 2004 at 08:12 UTC
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")` [download] (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$&	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: chroot a directory...
by muntfish (Chaplain) on Sep 10, 2004 at 08:12 UTC

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")
[download]

(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$&

[reply]
[d/l]
[select]