Getting started with 1Password for your growing team, or refining your setup? Our Secured Success quickstart guide is for you.
Forum Discussion
firelizzard
3 years agoNew Contributor
Calling the CLI from a Go program
I'm working on a Go program and I want to call op
, using the PolKit/app integration so a dialog appears prompting the user to type in their password. This works when I run op
directly from my shell, but it does not work when I exec op
from my Go program. So far what I have is effectively exec.Command("/usr/local/bin/op", ...).Output()
. However, that is failing with [ERROR] 2022/12/05 14:23:19 error initializing client: connecting to desktop app: read: connection reset, make sure the CLI is correctly installed and Connect with 1Password CLI is enabled in the 1Password app
. All --debug
does is add DEBUG | NM request: NmRequestAccounts
.
1Password Version: CLI 2.7.3, desktop 8.9
Extension Version: 2.3.8
OS Version: Gentoo Linux
Browser:_ Firefox
22 Replies
- Former Member
Quick update on this: we've now also released https://releases.1password.com/linux/8.10/. That means the fix is now available on all release channels.
- Former Member
Hey all!
Thanks for your patience. I'm checking back in to let you know that we released a new beta version of 1Password for Linux (https://releases.1password.com/linux/beta/#1password-for-linux-8.10.8-24) yesterday that should allow you to use the CLI from a program that itself is not owned by root. You can follow the instructions https://support.1password.com/betas/?linux to install a beta release of the app. The fix will also be included in the next minor stable release, which will be out in a few weeks.
Let me know if that fixes the problem for you.
Joris
- Former Member
Thank you everyone for digging into this and bringing this to our attention. Unfortunately we've got no updates to share at this point, but this is on our radar we'll make sure to let y'all know once this gets prioritised and eventually resolved. Thank you for your understanding!
Best,
Horia - Former Member
Jack_P_1P This restriction causes problems for any integrations with 1Password when the use has GUI integration enabled. This has broken some of my integration, as well as community tooling such as
kubectl-passman
. - Former Member
@smgt Your findings echo mine, I also found that unless the directory tree from the binary to the root directory is all owned by root it will fail. If any of the parent, grandparent etc directories are not root owned it will fail. I did my testing in /opt, /media and /home (below user specific directories).
- Former Member
After playing around a little more it seems to be certain criteria that needs to be fulfilled to make it work. You can not just run your Go program using
go run main.go
for example. The executable needs to be in some system executable dir like/usr/bin
or/usr/local/bin
. The executable needs to be owned by root,chown root:root exe
and the permissions needs to be 755,chmod 755 exe
. I haven't played around extensively with different users and permissions.
I've tried to run the exe from a path in my home dir (/home/$USER/bin
) that's in the path$PATH
but I don't seem to be able to run theexe
in that dir and make it work even if the owner isroot
and permissions are755
(rwxr-xr-x
).I'm planning to do the following to continue to develop the Go.
- Disable "Connect with 1Password CLI"
- Add a function to handle
op signin
session tokens - Develop
- Test
- During release move the compiled binary to
/usr/bin
and change user toroot
and permissions to755
- Enable "Connect with 1Password CLI"
- Former Member
I'm trying to build a CLI tool using go. Running into the same problems as mentioned above when "Connect with 1Password CLI" is enabled. I can get it to work if I use the regular session token.
- Jack_P_1P
1Password Team
Hi folks,
Sorry for the delay here. I don't have anything else to share just yet, but we are looking into solutions at this time.
Jack
- Former Member
@gunzy83 thanks so much for the details in your Feb 14th post. The op script workaround is a great find. Also, I agree with your sentiments that the binary permissions check seems more annoying than helpful and should be documented.
Jack_P_1P I don't suppose you have an update yet on this?
- Former Member
@asdfasdfasdfasdf the lookup plugin still does not support
op
v2: https://github.com/ansible-collections/community.general/issues/5303 so I think that is unrelated for now but once support is merged it will also be affected by this binary check issue if you are not using system python (owned by root).