Fix for incorrect GIDs for onepassword and onepassword-cli groups on a custom image
Symptoms
(See also ublue-os/bling issue #77)
You’ve integrated 1Password into your custom image, but its integration between the desktop application and either the browser extension or the op CLI don’t work.
Also, the GID is wrong:
$ ls -l /usr/bin/op
-rwxr-sr-x. 2 root 1600 22883536 Jan 1 1970 /usr/bin/op
$ ls -l /opt/1Password/1Password-BrowserSupport
-rwxr-sr-x. 4 root 1500 10080728 Dec 31 1969 /usr/bin/op
$ cat /etc/group
root:x:0:
wheel:x:10:tunix
tunix:x:1000:
docker:x:968:
gluster:x:967:
libvirt:x:966:
nm-fortisslvpn:x:965:
onepassword-cli:x:964:tunix
onepassword:x:963:
plugdev:x:962:
qemu:x:107:
saslauth:x:76:saslauth
unbound:x:961:
adbusers:x:960:
Cause
This is actually caused by having installed/layered 1Password and/or its CLI onto your system via the RPM package/1Password’s official install instructions, rather than integrating it directly into your custom image.
Even if you uninstall the RPM, the groups it makes may persist on your system.
The fix
Run this script on your system to fix the GIDs. (Your actual installed computer — no need to do anything to your custom image.)
Why does this happen?
In short, 1Password expects its privileged helper tools to be owned by their own groups, with a GID above 1000, but a chicken/egg problem prevents this from working as expected.
On a normal RPM-based system like Fedora Workstation, these special groups are created while installing the 1Password packages, and rpm-ostree does its best to create these groups. But on OSTree systems groups are dynamically created during or after booting the system.
Thus, to get around this issue, the 1Password install script in ublue-os/bling reserves GIDs 1500 and 1600 to use for the onepassword and onepassword-cli groups, and the group owner of the helper tools are set during image creation. (These reserved GIDs can be overridden via environment variables).
Then, a couple of files are dropped into /usr/lib/sysusers.d that declaratively define the groups with the reserved GIDs.
Unfortunately, systemd-sysusers (the utility that creates these groups on boot) can’t remove or renumber groups. Thus, if the RPM packages have been installed before, or for any other reason the onepassword and onepassword-cli groups already exist with different GIDs, the 1Password helper tools won’t be owned by the right groups.