fix: path sanitization to prevent directory containment bypass

[Hengkai-Ye]

This is a follow-up patch to #206

The previous patch did not fully prevent directory containment bypass. An attacker could still access paths like /path/to/allowed/directory-evil even when the allowed directory is set to /path/to/allowed/directory. This issue is similar to CVE-2025-53110 reported in another MCP server.

[GLips]

I think I'd like to change our logic in this check—see my comment in #224

remove the directory checking unless a specific --download-path is specified. I feel like it's rare for someone to run an MCP server in the exact directory they'd like to download images into, and this newly introduced limitation is more cumbersome than it is helpful.

[Hengkai-Ye]

Looks good to me, but should also pay attention to the potential directory containment bypass. BTW, how do you plan to handle the default path if --download-path is not specified, fully rely on LLM to decide?

[GLips]

Yeah, LLM decides I think. In the past that's how the MCP worked, and it seemed to work pretty well for most folks.

In terms of security, I do wish there was a better middle road I could think of.

As it is I think I'd like to preserve backward compatibility with how it was originally (i.e. unrestricted downloads) and provide the option to restrict the MCP server download path via CLI argument or env var.

Coding agents—where this MCP is most frequently used—already have tons of permissions in most environments. I feel like they largely default to unrestricted access at the moment. That being the case, I think it might be alright for us to do the same.