Hi, i need password-manager-service for hashicorp boundary ( application stores the tokens in the secret-service).
1 Like
And system-observe too.
name: 'boundary'
base: core22
version: 'v0.15.3'
summary: boundary
description: |
Boundary enables identity-based access management for dynamic infrastructure.
https://github.com/hashicorp/boundary
grade: stable
confinement: strict
architectures:
- build-on: amd64
- build-on: arm64
parts:
build-boundary:
plugin: go
source: https://github.com/hashicorp/boundary
source-type: git
source-tag: $SNAPCRAFT_PROJECT_VERSION
override-build: |
make build
install $SNAPCRAFT_PART_BUILD/bin/boundary -D $SNAPCRAFT_PART_INSTALL/bin/boundary
build-packages:
- build-essential
- jq
build-snaps:
- go
- docker
- node/18/stable
apps:
boundary:
command: bin/boundary
plugs:
- network
- network-bind
- system-observe
- password-manager-service
- desktop
- desktop-legacy
What kind of maneuver are we talking about? As I said earlier, the password-manager-service is needed so that the application can store tokens for subsequent sessions. I’m not sure about system-observe, it just throws errors without it.
❯ boundary authenticate oidc
Opening returned authentication URL in your browser...
.........
Unable to open authentication URL in browser: 1 error occurred:
* Unable to read /proc/1/cgroup: open /proc/1/cgroup: permission denied
Please copy and paste this link into a browser manually:
.............
Authentication information:
Account ID: acctoidc_orIEsyU5k8
Auth Method ID: amoidc_4W31SnCYCJ
Expiration Time: Mon, 08 Apr 2024 17:19:59 MSK
User ID: u_jUGc5eOGRX
Error opening "secret-service" keyring: Specified keyring backend not available
The token was not successfully saved to a system keyring. The token is:
.........
It must be manually passed in via the BOUNDARY_TOKEN env var or -token flag. Storing the token can also be disabled via -keyring-type=none.
Yes. And system-observe.
.You’ll most probably not get the auto-connection. Because password-manager-service isn’t allowed to auto-connect anymore. Rather on gnome and kde you can try portals and request others to connect manually.
Hi @metanovii,
@soumyaDghosh is right, access to password-manager-service gives the snap access to all session secrets, what does not fit great the confinement mode.
The secret-portal should do work in environments supporting it (gnome/kde). I will also support the manual connection for the password-manager-service after publisher vetting if the snap description enables the user to make an informed decision
Actually, here it has some big issues. Like, there is no example app in gnome world which uses this portals and the kde one is still kinda WIP.
I think the discussion is no longer actualy. I added instructions to the description of the project, like
snap install boundary
snap connect boundary:system-observe
snap connect boundary:password-manager-service
I gave it a try when reassessing the chromium and it worked really out of the box (with the supported gnome-keyring versions). I should be able to find the code I used if it helps.
1 Like
Hi @jslarraz can you kindly share the code changes that were needed to be done in the chromium source-code? It’ll be if this can fix some apps.
1 Like
Hey @soumyaDghosh
Sorry for the delay in my response. So, I’m not part of the chromium project and I don’t know if they did any update. What I did here was checking if libsecret works with the secret-portals as expected when run inside a snap.
I have created a gist including the snapcraft.yaml I used for the test and a readme walking through a simplified version of the checks.
Please let me know if you think any other resource will be more helpful in this regard
Thanks!
1 Like
A very strange decision. Are you restricting the app’s access to secret storage so that what? In addition, kwallet and others can act as a storage secret, what’s the point of not letting the application go to it? Considering that when trying to access storage secret, you need to enter a password.
Are you restricting the app’s access to secret storage so that what?
Application should only be able to access secrets created by itself and not all secrets in the system. That’s the point behind sandboxing applications. That’s not specific for snaps and it is part of the behavior of libsecret.
When libsecret detects that it is being used in a confined environment (i.e. it does not have raw access to the secret storage) it tries to access the secret storage via the secret-portal. In this case, Instead of storing the password directly to the secret storage, libsecret stores the password locally encrypted with an encryption secret unique to the application, which it is stored in the secret storage via the secret-protal.
All this magic is seamless to the application as libsecret handles it behind the scenes. Related PR can be found
https://gitlab.gnome.org/GNOME/libsecret/-/merge_requests/6
https://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/18
1 Like
Thanks for the links, I’ll read it.
in continuation of my request. What about system-observe? Without it, the application generates an error:
❯ boundary authenticate oidc
update.go:85: cannot change mount namespace according to change mount (/var/lib/snapd/hostfs/boot /boot none bind,ro 0 0): permission denied
Opening returned authentication URL in your browser...
https://git....
Unable to open authentication URL in browser: 1 error occurred:
* Unable to read /proc/1/cgroup: open /proc/1/cgroup: permission denied
Whilst needing system-observe looks a bit odd, I gave it a try and ran into the same issue. Thus, if other reviewers don’t oppose I’ll be happy to support that request