Security implications of using open() on untrusted strings.

[r0g]

Steven D'Aprano wrote:
> On Mon, 24 Nov 2008 00:44:45 -0500, r0g wrote:
> 
>> Hi there,
>>
>> I'm trying to validate some user input which is for the most part simple
>> regexery however I would like to check filenames and I would like this
>> code to be multiplatform.
>>
>> I had hoped the os module would have a function that would tell me if a
>> proposed filename would be valid on the host system but it seems not. I
>> have considered whitelisting but it seems a bit unfair to make the rest
>> of the world suffer the naming restrictions of windows. Moreover it
>> seems both inelegant and hard work to research the valid file/directory
>> naming conventions of every platform that this app could conceivably run
>> on and write regex's for all of them so...
> 
> That's probably why nobody has written a function for the os module to do 
> the same... and just wait until you get into the murky universe of cross-
> platform Unicode filenames.
> 
> Honestly, I think your best bet is to just trust the file system to 
> recognize a bad file name and raise an exception. What counts as a bad 
> file name is surprisingly hard to define, especially if you want to be 
> cross-platform. See here for more details:
> 
> 
> http://stackoverflow.com/questions/295135/turn-a-string-into-a-valid-
> filename-in-python
> 
> 

Yep, I spotted that too which is why white-listing is my fallback plan.
My question is really about the security of using unfiltered data in a
filesystem function though. Are there particualar exploits that could
make use of such unfiltered calls? For example I'd imagine jailbreaking
might be a concern if the app isn't run under it's own restricted user
account. Do others here consider this when designing applications and
what techniques/modules, if any, do you use to sanitize path/filename input?

Roger.