mount arbitrary file into container service?

[akluiber]

Hi all,

Just wondering is it currently possible to mount an arbitrary file path into the container service via the json command definition?

I see the following in the documentation, and was wondering if that's still the case and whether it was on the roadmap for implementation?

Directory, File, and File[] inputs are possible to make, but the files the refer to cannot be mounted.

[John Flavin]

We don't allow mounting arbitrary files, only files from within the XNAT archive that the launching user has permission to see. That's by design. If you could mount arbitrary files from the archive, an attacker could easily break the XNAT security model. And if you could mount arbitrary files from anywhere on the file system, an attacker could take over the entire compute node and most likely the XNAT.

John Flavin

--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/xnat_discussion/41189b24-a2f9-4726-8c63-7ab28ec150f8n%40googlegroups.com.

[akluiber]

Ah understood. Makes sense.

I don't suppose there's a site-wide or user-specific context available to the container service for mounting files, is there? I know that the Jupyter service can use the user workspaces, but I assume that's plugin specific. I ask because I need to use ssh key authentication inside the container service to issue commands to another analysis server - which cannot be included as part of a swarm - and I just didn't want to have to store keys as resources across multiple projects if I could avoid it.

[Moore, Charlie]

That sounds like a use case for the secrets feature in container service: https://wiki.xnat.org/container-service/making-use-of-container-service-secrets . It seems a bit clunky to shove an entire ssh key into a system property, but it sounds like it would probably work to:
1. Put whole ssh key into system property available to tomcat.

2. Then read the secret in as environment variable in the command

3. Then write the environment variable to an actual key file within the container.

It would be much cleaner if there was a true implementation of this type of secret, but I don't think there's been enough of an impetus into a v2 of CS secrets.

Thanks,

Charlie Moore

---

From: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com> on behalf of akluiber <al...@kluiber.net>
Sent: Tuesday, February 3, 2026 2:10 PM
To: xnat_discussion <xnat_di...@googlegroups.com>
Subject: Re: [XNAT Discussion] mount arbitrary file into container service?

 

To view this discussion visit https://groups.google.com/d/msgid/xnat_discussion/e3e505b3-635b-4e51-87e0-d031757701a6n%40googlegroups.com.

 

---

The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

[John Flavin]

It would be much cleaner if there was a true implementation of this type of secret, but I don't think there's been enough of an impetus into a v2 of CS secrets.

The Secrets have been somewhat neglected, it is true. But it was designed to be easy to expand with new sources and destinations. Wouldn't take too much effort for an XNAT dev to add a File secret source. 

John Flavin

To view this discussion visit https://groups.google.com/d/msgid/xnat_discussion/CH3PR02MB974896D5480E268BB08CEC07FE9BA%40CH3PR02MB9748.namprd02.prod.outlook.com.

[akluiber]

Thanks all. I am indeed able to get the secrets to work. I know one topic of discussion I've seen before is using how people use XNAT with HPCs. This is what I'm testing out. The current secrets method does seem to expose the key string in a few places (catalina log, tomcat.conf). Not totally ideal, but at least those files can be permissions restricted well enough. Not really any different than the keyfile on the file system then.

Personally, I could see the value in a feature which would allow one to securely store at the system, project, and/or user context levels, persistent variables for use with the container service, such as keys or tokens like these.