Calling the CLI from a Go program

firelizzard

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

firelizzard

I figured it out. Both the executable that calls op and the directory that executable is in must be owned by root.

Jack.P_1P

Hi @firelizzard:

Thanks for reaching out about this. This is something we're aware of, and I've added you as affected to our internal tracking issue.

Jack

ref: dev/core/core#18349

firelizzard

@Jack.P_1P, thanks for the update. I have a workaround (chmod root:root) but the behavior is odd and it does make it considerably harder to use a debugger on my executable. I tried to reproduce it with a test executable in place of op but I could not replicate the owner-dependent behavior. I tried running op with strace, but that gave me the same error. I read that ptrace no longer respects setuid/setgid bits because of potential vulnerabilities, but I expected to see a failed setgid syscall, which I did not see. So I guess op is using the effective GID or doing some other magic.

Jack.P_1P

You're very welcome.

rsyring

Any resolution to this? I'm having the same problem trying to call op from a Python script.

Additionally, setting the python binary and it's directory to be owned by root did not resolve my issues.

Logs. First one shows successful signin from bash CLI. Second one shows attempt from Python using it's subprocess module.

INFO 2022-12-23T03:05:50.345 tokio-runtime-worker(ThreadId(10)) [1P:native-messaging/op-native-core-integration/src/lib.rs:305] Extension connecting.
INFO 2022-12-23T03:05:50.345 tokio-runtime-worker(ThreadId(10)) [1P:native-messaging/op-native-core-integration/src/lib.rs:307] Extension connection accepted.
ERROR 2022-12-23T03:05:54.467 tokio-runtime-worker(ThreadId(2)) [1P:native-messaging/op-native-core-integration/src/connection_handler.rs:60] message from b5x was None: EndConnection
ERROR 2022-12-23T03:05:54.467 tokio-runtime-worker(ThreadId(2)) [1P:native-messaging/op-native-core-integration/src/connection_handler.rs:31] Dropping connection with b5x due to error handling incoming message: EndConnection
WARN 2022-12-23T03:06:14.128 tokio-runtime-worker(ThreadId(2)) [1P:foundation/op-sys-info/src/process_information/linux.rs:247] binary permission verification failed for /shared/apps/pyenv/versions/3.10.6/bin/python3.10
INFO 2022-12-23T03:06:14.128 tokio-runtime-worker(ThreadId(2)) [1P:native-messaging/op-native-core-integration/src/lib.rs:305] Extension connecting.
ERROR 2022-12-23T03:06:14.128 tokio-runtime-worker(ThreadId(2)) [1P:native-messaging/op-native-core-integration/src/lib.rs:477] Failed to accept new connection.: PipeAuthError(UnknownPeer(BinaryPermissions))

rsyring

I'd add this to my past comment but it is apparently being moderated:

$ op --version
2.12.0
$ 1password --version
8.9.10