Classic confinement request: ida-mcp

store-requests classic-confinement
1

name: ida-mcp description: Headless MCP server exposing IDA Pro’s analysis engine to AI assistants over the Model Context Protocol. Lets agents disassemble, decompile, and inspect binaries through an idalib session. snapcraft: ida-mcp-rs/snap/snapcraft.yaml at main · blacktop/ida-mcp-rs · GitHub upstream: GitHub - blacktop/ida-mcp-rs: Headless IDA Pro MCP Server · GitHub upstream-relation: I am the author and maintainer. supported-category: debug tools reasoning: ida-mcp dynamically links against libida.so and libidalib.so from a user-installed IDA Pro at arbitrary host paths (~/ida-pro-9.3, /opt/ida-pro-9.3, or wherever the user ran the Hex-Rays installer). These are proprietary, non-redistributable runtime libraries — they cannot be staged into the snap. The binary resolves them at runtime via a launcher script that sets LD_LIBRARY_PATH from the user’s install location.

Strict confinement cannot reach arbitrary host paths. The home interface exposes ~/snap/ida-mcp/, not the user’s actual home where IDA lives. system-files would require enumerating every possible install path at build time, which defeats the point — users install IDA wherever they want.

This matches the documented criterion “access to files on the host outside the snap’s runtime (eg, /usr)”.

  • I understand that strict confinement is generally preferred over classic.
  • I’ve tried the existing interfaces to make the snap work under strict confinement.
2

This request has not been added to the review queue. It should be placed in the appropriate store-requests subcategory using the subcategory template for classic-confinement, privileged-interfaces and aliases requests.

3

should be fixed now; please take another look

4

This request has been added to the queue for review by the @reviewers team.

5

Hello @blacktop!

Even though your snap does fall under the supported categories for classic, the project seems to be very fresh, according to the upstream repository and I could not find evidences that the project has a strong enough user base currently. Thus, it is currently not a good candidate for classic confinement (#reject).

If you need further assistance, feel free to share your questions :slight_smile:

6

Even though the request has already been rejected, there are some comments I’d like to add…

This is actually not true, the home interface grants access to all non-hidden files and folders in the users home, note though that the $HOME variable automatically points to $SNAP_DATA so your app should use a different way than the environment variable to access the home dir.

Also note that even classic confined snaps can not/should not use any libaries from outside the snap to be able to start the contained application, if libida.so and libidalib.so would be required from outside the snap to actually run the application this would also be a blocking factor.