[RESOLVED] - Sctl didn't need personal-files

store-requests
#1

Greetings,

I’ve written a secret management tool named sctl. I just registered the snap this morning and have been toying with builds for a few days now. As the tool reads various .scuttle.json files found in repositories, the home / network plug would provide insufficient permissions for sctl to operate. I’ve also confirmed use of “personal-files” seems to be insufficient as well as i’d need a full glob pattern, and i have no idea what that would really equate to since anything under any path could potentially contain a .scuttle.json state file.

If you’d like to peruse the code, here’s a link to the direct code blocks that would be blocked:

https://github.com/vapor-ware/sctl/blob/master/util.go#L64-L86

While I’m testing, trying to get this into the edge channel - the stores automated review blocks a release for QA.

Ergo, sctl needs classic confinement.

Thanks and all the best

1 Like
#2

In the spirit of documenting my journey, I’ve run across a post for a similar tool that looks like I may get away with classic and some caveats.

jdstrand outlines that the home and removable-media plugs would allow access to .scuttle.json files that aren’t in the top level of $HOME. Which does work as advertised. I think with that little nugget we can close this topic, and I’ll progress forward with the classic security model and document the caveats due to the security model of snaps.

#3

Next blocker has been uncovered, and I’m not sure how the google-cloud-sdk snap functions without classic or personal-files.

I’ve identified that i’ll need to use personal-files interface to grant access to $HOME/.config/gcloud, but the environment variables being stripped are causing some heartburn. I’m able to successfully set the configuration for the KMS key, however its not picking up that it can read and is configured, to use an application default credential.

I’m not seeing how https://github.com/OddBloke/google-cloud-sdk-snap/blob/c70c714b613aa2b8cd355a858102c1adb0b2aee1/snapcraft.yaml grants access to the files in strict mode. So this must not be the snapcraft yaml that’s publishing this snap?

The search for details continues

– edit –

Yeah, looks like the google-cloud-sdk has classic confinement. Ok, something’s got to give with how i have this structured, I think i’m just not getting an ENV configuration that i’m expecting…

– another edit, because i’m hacking –

Yep, works when i statically configure it after connecting the personal-files interface. This is because $HOME is getting translated to the snap home. back to the env listing…

#4

What i’ve done here is a pretty gross hack…

Since snappy overrides $HOME, and tbqh i need this, i’ve just derived based on $USER, which is sure to break under some circumstances. But I didn’t see any environment variables i could use to refer to $HOME, even when i’ve connected up all the interfaces.

It’s documented as a FIXME hack, and hopefully i’ll either run into a better example, or derive a better way to determine the real $HOME.

but as a benefit it now uses snap configuration to derive its KMS key. I guess I could just set the path to $GOOGLE_APPLICATION_DEFAULT_CREDENTIAL to a configuration key and skip the derivation…

#5

You can use something like getent passwd $(id -u) | cut -d ':' -f 6 to get the real home directory.

At this point, it is unclear to me what the request is. Can you restate your request?

1 Like
#6

Certainly!

Thank you for finding this request and attempting to decypher my trial of notes here… sorry about the mess. i initially opened the request before I had fully grasped what I needed or rather, what the problem domain was.

I’ve written a tool here that manages secrets using “files on disk” in $PWD. It relies on 2 things that concern snap packaging:

  1. write access to $PWD
  2. A functional, and configured version of the gcloud sdk (for authentication/authorization)

I’ve managed to get sctl to function correctly in a snap thats living in my edge channel of the sctl repository. I’ll dig into the suggestion for how to derive the GOOGLE_APPLICATION_CREDENTIAL from the google-cloud-sdk snap, but still requires me to request an override “personal-files” interface to actually read from the location provided for $GOOGLE_APPLICATION_CREDENTIAL. which at present is in $HOME/.config/gcloud/application_default_credentials.json.

If there is a comparable working solution to isolate and not need the personal-files interface, that would be ideal. However I’ve not had a positive test in full confinement as it doesn’t appear you can override the gcloud-sdk cache workspace, so here I am, asking for personal-files :slight_smile:

#7

AIUI, you need read-only access to ~/.config/gcloud/application_default_credentials.json. Reading https://cloud.google.com/sdk/gcloud/reference/auth/application-default/, it says “These credentials are only used by Google client libraries in your own application.” This suggests to me that the most appropriate place would be to access the snap-specific $HOME, ie ~/snap/sctl/<revision>/.config/gcloud/application_default_credentials.json. Why does your snap need access to the global application default credentials file?

1 Like
#8

Oh hey that worked! nice :vulcan_salute:

I think you can mark this as closed since there’s a viable working solution that doesn’t require classic or personal files. Thanks for helping me arrive at this destination @jdstrand

2 Likes
#9

I’m into the same thinking … i’ve an Ubuntu Core environment where i’m pasting the GOOGLE_APPLICATION_CREDENTIALS.json token, i’m setting the env variable GOOGLE_APPLICATION_CREDENTIALS=/path/to/token after that i install the snap with node.js code that need to be auth with the token but i cant access the token …

Which the best solution / right method to link the GOOGLE_APPLICATION_CREDENTIAL ?

My actual solution is to copy the file i need into the $SNAP_USER_COMMON path after the snap is installed !