Changing GELI password, is this the proper workflow?

[resilient294]

I tried changing the GELI encryption password on a testing pc with an encrypted ZFS hard drive, and it seemed too easy to have done it the right way. What am I doing wrong?

ls /dev/ | grep eli

- to check the root partition

geli delkey -a /dev/ada0p3

- to destroy the old Master Key copy

geli setkey /dev/ada0p3

- for a prompt with the new password

Is this the recommended way to change an encryption password? I was surprised that I could enter every command with regular user privileges, which is kind of scary when you think that anyone with access to someone's user account can lock them out of their pc.

 

[monwarez]

Pretty sure you are in the operator groups. The operator group give additional privilege related to partition, and backing up storage.

 

[resilient294]

Pretty sure you are in the operator groups. The operator group give additional privilege related to partition, and backing up storage.

Thank you! Yes, the user is part of the `operator` group. I have two additional questions before attempting these changes on my main machine. Are `delkey` and `setkey` the only changes that I need to do in order to safely change the encryption password? Is it safe to remove myself from the `operator` group on an everyday pc without causing any dependency issues? Thanks a lot for the help.

 

[T-Daemon]

geli(8) "delkey" is not mandatory. "setkey" will overwrite previous keys (both master key copies).

Make sure to backup the geli(8) metadata file(s) under /var/backups off-site (on another device), just in case. Better save than sorry:

Example:

 # ls /var/backups | grep .eli
ada0p3.eli
ada1p1.eli
ada2p1.eli

I would also backup the whole /var/backups directory. To name important ones from periodic backups: gpart, group, master.passwd, *.eli.

 

[resilient294]

geli(8) "delkey" is not mandatory. "setkey" will overwrite previous keys (both master key copies).

Make sure to backup the geli(8) metadata file(s) under /var/backups off-site (on another device), just in case. Better save than sorry:

Example:

 # ls /var/backups | grep .eli
ada0p3.eli
ada1p1.eli
ada2p1.eli

I would also backup the whole /var/backups directory. To name important ones from periodic backups: gpart, group, master.passwd, *.eli.

Thanks. One more question, does it cause any issues if I remove my user from the operator group on a system that has been built with the user in this group since the beginning?

 

[T-Daemon]

One more question, does it cause any issues if I remove my user from the operator group on a system that has been built with the user in this group since the beginning?

There are no issues, unless the unprivileged user is granted permissions to shutdown, reboot the machine, for example.

Or some ports require to make the user member of the "operator" group, to grant them device access, mostly to USB and MTP devices:

Spoiler

% find /usr/ports -name pkg-message -exec grep -i operator {} + | sort
/usr/ports/audio/beep/pkg-message:# Allow members of group operator to cat things to the speaker
/usr/ports/audio/beep/pkg-message:% pw groupmod operator -m jerry
/usr/ports/audio/beep/pkg-message:Add a user to operator group:
/usr/ports/audio/beep/pkg-message:For PC speaker sound to work you need to be in the operator group
/usr/ports/audio/beep/pkg-message:add path 'speaker' mode 0660 group operator
/usr/ports/deskutils/calibre/pkg-message:# pw groupmod operator -m yourusername
/usr/ports/deskutils/calibre/pkg-message:add path 'usb/*' mode 0660 group operator
/usr/ports/deskutils/calibre/pkg-message:to be a member of the operator group:
/usr/ports/devel/openocd/pkg-message:        add path 'ugen*' mode 0660 group operator
/usr/ports/devel/openocd/pkg-message:        add path 'usb' mode 0770 group operator
/usr/ports/devel/openocd/pkg-message:        add path 'usb/*'  mode 0660 group operator
/usr/ports/devel/openocd/pkg-message: add him/her to the operator group  (pw groupmod operator -m username), then
/usr/ports/emulators/qemu-devel/pkg-message:    add path 'ugen*' mode 660 group operator
/usr/ports/emulators/qemu/pkg-message:    add path 'ugen*' mode 660 group operator
/usr/ports/emulators/qemu8/pkg-message:    add path 'ugen*' mode 660 group operator
/usr/ports/emulators/virtualbox-ose-legacy/pkg-message:% pw groupmod operator -m jerry
/usr/ports/emulators/virtualbox-ose-legacy/pkg-message:For USB support your user needs to be in the operator group and needs read
/usr/ports/emulators/virtualbox-ose-legacy/pkg-message:add path 'usb/*' mode 0660 group operator
/usr/ports/mail/postgrey/pkg-message:- Someone who goes to that link may disclose to the website's operator that
/usr/ports/multimedia/libcec/pkg-message:% pw groupmod operator -m jerry
/usr/ports/multimedia/libcec/pkg-message:Consider adding your user to the operator group:
/usr/ports/multimedia/libcec/pkg-message:add path 'ttyU*' mode 0660 group operator
/usr/ports/multimedia/ogmrip/pkg-message:Any user from the "operator" group should then be able to access those devices
/usr/ports/sysutils/dsbbatmon/pkg-message:    # pw groupmod operator -m yourusername
/usr/ports/sysutils/dsbbatmon/pkg-message:NOTE: On FreeBSD >= 12, members of the operator group are allowed to
/usr/ports/sysutils/dsbbatmon/pkg-message:use sudo(8) (see below), or you can add your username to the operator
/usr/ports/sysutils/py-blinkstick/pkg-message:# pw group mod operator -m <user>
/usr/ports/sysutils/py-blinkstick/pkg-message:must belong to the operator group. You can add them with the command:

See also 3.3.3. Managing Groups

Warning
Care must be taken when using the operator group, as unintended superuser-like access privileges may be granted, including but not limited to shutdown, reboot, and access to all items in /dev in the group.