On Tue, Mar 29, 2016 at 1:41 PM, Paul Moore p.f.moore@gmail.com wrote:
On 29 March 2016 at 11:24, Koos Zevenhoven k7hoven@gmail.com wrote:
As we all know, togo is user input containing ../../../../../../../../../../../../../../../etc/passwd
How about
p'/' /wherever/youwant//togoThat is, the floordiv operator could be used to prevent 'togo' from going up the directory tree with "../../" or "/etc/passwd". The // would thus restrict the user (who provides `togo`) into /wherever/youwant/ and it its subdirectories.
There have been a number of previous threads about the security of path objects (and for that matter of os.path) and "sandboxing" paths to disallow traversing "up" out of a particular directory.
I've no idea whether the floordiv operator would work for this purpose (I'm not a security expert, and most of my personal applications can afford to take a very lax view of such things, luckily) but it's an interesting idea. Potentially, it's a bit easy to miss, which may be a problem.
Actually, after having looked into RFC 3986s, I'd say using | instead of // for the path sandboxing operator may be better for at least two reasons:
1a. Because // is used in relative references for URIs to mean essentially 'go all the way up to scheme://', which is quite opposite to the concept of sandboxing.
1b. Because | kind of looks like a wall.
2. Because | has lower precedence than /, meaning that
dontmesswiththis | relative / paths == dontmesswiththis | (relative / paths)
while
dontmesswiththis // relative / paths == (dontmesswiththis // relative) / paths
So unless (dontmesswiththis // relative) somehow remembers the sandboxing barrier, the | would do the right thing and // the wrong thing. Then of course you might want it to remember the barrier anyway.
I won't open the pandora's box in front of myself now regarding the old threads you mention. But if someone else wants to do that and/or there is something to discuss regarding this, I suggest to move the sandboxing discussion to a new thread.
-Koos