Skip to main content
March 31, 2022
Question

op CLI with biometric unlock using Polkit not working

  • March 31, 2022
  • 13 replies
  • 1330 views

Hi,
I'm using 1Password 8.6.1-1 and CLI 2.0.0-4 from the Arch User Repo. I usually use i3-gnome-flashback, but I see the same problem under GNOME on Wayland, or GNOME Flashback. I appreciate the i3 setup is a bit niche, and am happy to fix that myself if anyone can help me getting it working under a plain old GNOME + Wayland or Xorg session. :)

Here's some info about my installation:

shell
$ pacman -Qi 1password 1password-cli | grep -iE '^(Name|Version)'
Name : 1password
Version : 8.6.1-1
Name : 1password-cli
Version : 2.0.0-4
$ pacman -Ql 1password | grep -i polkit
1password /usr/share/polkit-1/
1password /usr/share/polkit-1/actions/
1password /usr/share/polkit-1/actions/com.1password.1Password.policy
$ op --version
2.0.0
$ 1password --version
8.6.1
$ ls -lL $( which op )
-rwxr-sr-x 1 root onepassword-cli 12664832 Mar 30 16:41 /usr/bin/op
$ ls -lL $( which 1password )
-rwxr-xr-x 1 root root 149375632 Mar 30 16:42 /usr/bin/1password
$ getent group | grep onepassword
onepassword-cli:x:1011:
onepassword:x:1012:
$ ss --listening | grep -i pass | column -t ; ls -la ${XDG_RUNTIME_DIR}/1Password-BrowserSupport.sock
nl UNCONN 0 0 uevent:keepassxc/53952 *
nl UNCONN 0 0 uevent:keepassxc/53952 *
u_str LISTEN 0 50 /tmp/qtsingleapp-Enpass-216b-3ed 25210 * 0
srw------- 1 my_username my_username 0 Mar 31 15:08 /run/user/my_uid/1Password-BrowserSupport.sock

Using the old method of adding an account manually works. Using e.g. eval $( secret-tool lookup provider 1Password profile work | op signin --account work) makes creds in my work vault available to the CLI using op item get etc. I would like to switch to the "biometric" (Polkit) unlock.

The 1Password GUI client setting Unlock using system authentication service works: I haven't ever had a problem with this.

I have read and followed https://developer.1password.com/docs/cli/about-biometric-unlock and https://developer.1password.com/docs/cli/get-started#sign-in. Whether the GUI client is running and unlocked or not, I do not get prompted to choose an account (I only have one). Instead, I get this:

```shell
$ op vault ls
No accounts configured for use with 1Password CLI.

You can either:
- Sign in with biometric unlock; see https://developer.1password.com/docs/cli/get-started/#sign-in for details.
- Add an account manually with op account add; see op account add --help for details.

Do you want to add an account manually now? [Y/n]
```

I saw the issues with the group ID being under 1000, and ensured that was not the case. The Polkit actions template appears to have been rendered correctly: in any case, if I manually install the template, replacing the placeholders with unix-user:my_username, I still see this issue. Other Polkit actions and rules work fine, e.g. GParted prompts me to enter credentials, then runs as expected.

Please let me know if I can provide more information for troubleshooting.


1Password Version: 8.6.1
Extension Version: 2.3.2
OS Version: Arch Linux (rolling)

13 replies

April 7, 2022

had the same issue on arch (also gnome-flashback + i3)
I fixed it by changing the ownership of the op binary:


sudo chown root:onepassword-cli /usr/bin/op
sudo chmod g+s /usr/bin/op

Found this somewhere in the 1Pass CLI Guide

April 8, 2022

Hey, sorry just realized how absolutely unhelpful my first response was.

I just checked on my Ubuntu work laptop and the sockets appear a bit different:

```
awe@ubuntu:~$ ss --listening | grep -i pass | column -t ; ls -la ${XDG_RUNTIME_DIR}/1Password-BrowserSupport.sock
nl UNCONN 0 0 rtnl:1password/5328 *

nl UNCONN 0 0 rtnl:1password/5221 *

nl UNCONN 0 0 rtnl:1password/5328 *

nl UNCONN 0 0 rtnl:1password/5221 *

nl UNCONN 0 0 uevent:1password/5221 *

nl UNCONN 0 0 uevent:1password/5221 *

u_str LISTEN 0 1024 /home/awe/.1password/agent.sock 64670 * 0
u_str LISTEN 0 1024 /run/user/1000/1Password-BrowserSupport.sock 62849 * 0
srw------- 1 awe awe 0 Apr 8 08:06 /run/user/1000/1Password-BrowserSupport.sock

```
Everything else was the same as yours permision-wise.
I will check my Arch machine later when i get home and see what i find there.

April 19, 2022

@awe thank you very much for taking the time to reply!

After several days worth of updates (and a couple of reboots), I now see these listening sockets:


ss --listening | grep -i 1pass | column -t ; ls -la ${XDG_RUNTIME_DIR}/1Password-BrowserSupport.sock
nl UNCONN 0 0 rtnl:1password/143290 *
nl UNCONN 0 0 rtnl:1password/143335 *
nl UNCONN 0 0 rtnl:1password/143335 *
nl UNCONN 0 0 rtnl:1password/143290 *
nl UNCONN 0 0 uevent:1password/143290 *
nl UNCONN 0 0 uevent:1password/143290 *
u_str LISTEN 0 1024 /run/user/my_uid/1Password-BrowserSupport.sock 169087 * 0
srw------- 1 my_username my_username 0 Apr 14 11:29 /run/user/my_uid/1Password-BrowserSupport.sock

NB: I modified the grep to exclude KeePassXC, which I also use.

April 20, 2022

Hey @ClaranM

I just checked on my Arch machine and got the following output:

awe@arch:~$ ss --listening | grep -i 1pass | column -t ; ls -la ${XDG_RUNTIME_DIR}/1Password-BrowserSupport.sock
nl UNCONN 0 0 rtnl:1password/2990 *
nl UNCONN 0 0 rtnl:1password/3042 *
nl UNCONN 0 0 rtnl:1password/3042 *
nl UNCONN 0 0 rtnl:1password/2990 *
nl UNCONN 0 0 uevent:1password/2990 *
nl UNCONN 0 0 uevent:1password/2990 *
u_str LISTEN 0 1024 /run/user/1000/1Password-BrowserSupport.sock 34387 * 0
u_str LISTEN 0 1024 /home/awe/.1password/agent.sock 42503 * 0
srw------- 1 awe awe 0 20. Apr 17:23 /run/user/1000/1Password-BrowserSupport.sock

I suppose you are missing the

u_str LISTEN 0 1024 /home/$USER/.1password/agent.sock

Did you install via the AUR?

April 22, 2022

Hi @awe, thank you for persisting, looks right to me.

Yes, I installed (and reinstalled) via the AUR. Reinstalling with makepkg --cleanbuild --force --syncdeps --install for both 1password and 1password-cli didn't help.

shell
$ pacman -Q | grep -i 1pass
1password 8.6.1-1
1password-cli 2.0.1-1
rofi-1pass 1.0-3

Since I can't find related issues, it looks like a problem with my config. Maybe some hardening tweak I made and forgot? ss --listening | grep -i \.sock | column -t | grep home returns zero results. I'll disable AppArmor and LSM config and try again.

shell
$ cat /proc/cmdline | tr " " "\n"
initrd=\intel-ucode.img
initrd=\initramfs-linux.img
zfs=zfsroot/ROOT/arch-linux
rw
resume=PARTUUID=my_partuuid
acpi_rev_override=1
apparmor=1
audit=1
lsm=lockdown,yama,apparmor
i915.fastboot=1
i915.enable_guc=2
pcie_aspm=off
nouveau.modeset=0
modprobe.blacklist=nouveau
nvidia_drm.modeset=0
modprobe.blacklist=nvidia_drm
x86_reserve_low=160
systemd.unified_cgroup_hierarchy=1

April 22, 2022

EDIT: This was all on another PC which had no LSM or AppArmor config, and on which 1Password had never been installed.

Maybe not. :/ I just checked on another machine without any generic hardening config (newish gaming PC) and still don't see /home/my_user/.1password/agent.sock. The other results were all present, except the browser integration, which I didn't bother to install. This was a clean install: neither 1Password GUI nor CLI were ever previously installed on this hardware.

Even without that missing agent.sock, "biometric" login worked fine on this 2nd PC.

April 22, 2022

(Back on the original PC)

Sadly, disabling AppArmor & LSMs did not help:

shell
$ cat /proc/cmdline | tr " " "\n"
initrd=\intel-ucode.img
initrd=\initramfs-linux.img
zfs=zfsroot/ROOT/arch-linux
rw
resume=PARTUUID=ef6e11b5-1d73-49b5-8785-9334434626d0
acpi_rev_override=1
i915.fastboot=1
i915.enable_guc=2
pcie_aspm=off
nouveau.modeset=0
modprobe.blacklist=nouveau
nvidia_drm.modeset=0
modprobe.blacklist=nvidia_drm
x86_reserve_low=160
systemd.unified_cgroup_hierarchy=1
$ systemctl status apparmor.service
○ apparmor.service - Load AppArmor profiles
Loaded: loaded (/usr/lib/systemd/system/apparmor.service; disabled; vendor preset: disabled)
Active: inactive (dead)
$ aa-enabled
No - disabled at boot.

Definitely looks like user error (mine!). Of potential interest is that running op vault ls on the original PC without the 1Password GUI running gives:

```shell
No accounts configured for use with 1Password CLI.

You can either:
- Sign in with biometric unlock; see https://developer.1password.com/docs/cli/get-started/#sign-in for details.
- Add an account manually with op account add; see op account add --help for details.

Do you want to add an account manually now? [Y/n]
```

While on the 2nd PC, I get:

shell
[ERROR] YYYY/MM/DD HH:MM:ss connecting to desktop app: cannot connect to to 1Password app, make sure it is running

April 26, 2022

Hey!

I am sorry for the late reply from our side. I see @awe already provided some great tips. Let me see what I can do for you.

Judging from the No accounts configured for use with 1Password CLI. response from the CLI, it looks like the CLI has some trouble determining whether CLI biometric unlock is enabled in the 1Password app.

There are two things we could try:

First of all, you could try running the following command to see if something goes wrong when determining the configuration of the 1Password app:

OP_LOAD_DESKTOP_APP_SETTINGS=true op vault ls

I expect this to return an error that points us in the direction of the problem.

Secondly, you could use OP_BIOMETRIC_UNLOCK_ENABLED to force the CLI to connect to the 1Password app. For example:

OP_BIOMETRIC_UNLOCK_ENABLED=true op vault ls

This should tell us whether the rest of the integration with the 1Password app is working correctly.

Could you let me know what those commands output?

Cheers,
Joris

April 26, 2022

Hi Joris,
Argh! Your first tip solved this:

shell
OP_LOAD_DESKTOP_APP_SETTINGS=true op vault ls
[ERROR] 2022/04/26 18:21:57 could not load desktop app settings: read file: Can't continue. We can't safely access "/home/my_user/.config/1Password/settings/settings.json" because its permissions are too broad. Change its permissions to 600 and try again.

chmod 0600 ~/.config/1Password/settings/settings.json fixed the issue, thanks.

Is there somewhere I should have looked to find these debug environment variables?

PS: Note to future readers: I reverted all other changes (e.g. AppArmor, LSM): the only change required was the chmod.

Cheers,
Ciaran.

April 26, 2022

Hi Ciaran,

Great to hear it has been resolved! The idea is generally that using the --debug flag should help you in these cases. However, we're still working on getting this error message printed when using --debug, hence the need for this undocumented environment variable to "trick" the CLI into printing it.

We have seen a few other reports about this specific error. In most cases it was linked to having participated in the beta of SSH key management for our 1Password 8 apps. Did you by any chance participate in that? That could help us determine where this problem originates in the first place.

Joris