On Fri, Dec 02, 2022 at 10:28:10AM +0000, Luca Boccassi wrote: > On Fri, 2 Dec 2022 at 08:48, Christian Brauner <brauner@xxxxxxxxxx> wrote: > > > > On Fri, Dec 02, 2022 at 12:36:10AM +0000, luca.boccassi@xxxxxxxxx wrote: > > > From: Luca Boccassi <bluca@xxxxxxxxxx> > > > > > > Usually when closing a crypto device (eg: dm-crypt with LUKS) the > > > volume key is not required, as it requires root privileges anyway, and > > > root can deny access to a disk in many ways regardless. Requiring the > > > volume key to lock the device is a peculiarity of the OPAL > > > specification. > > > > > > Given we might already have saved the key if the user requested it via > > > the 'IOC_OPAL_SAVE' ioctl, we can use that key to lock the device if no > > > key was provided here and the locking range matches. This allows > > > integrating OPAL with tools and libraries that are used to the common > > > behaviour and do not ask for the volume key when closing a device. > > > > > > If the caller provides a key on the other hand it will still be used as > > > before, no changes in that case. > > > > > > Suggested-by: Štěpán Horáček <stepan.horacek@xxxxxxxxx> > > > Signed-off-by: Luca Boccassi <bluca@xxxxxxxxxx> > > > --- > > > > But it would be quite the change in behavior for existing users, no? > > > > It might be better to add an ioctl that would allow to set an option on > > the opal device after it was opened which marks it as closable without > > providing the key? > > Closing with a zero-length key could not work before and would fail > with eperm, so I can't imagine anyone using it as such, so I didn't > bother. That's not the point though. Afaict, with your change users that rely on the device only being closable by users that have access to the key couldn't rely on his anymore. At least that's what the change description seems to imply.
