search

openSUSE / sdbootutil

MIT License
27 stars 14 forks source link

Enroll only cr_ prefixed devices #147

Closed TobiPeterG closed 3 weeks ago

TobiPeterG commented 1 month ago

This will fix the issue that all devices in crypttab are enrolled, even though this might not be desired. This implementation also will not replace the crypttab file, but only update it. This also creates a backup of the old file.

Please verify that this works as exected on different machines and use-cases

TobiPeterG commented 1 month ago

This doesn't rewrite the remove_crypttab_option yet, but that should, if the functionality proposed here is wanted, should also be done :)

aplanas commented 1 month ago

I was thinking in a different approach instead of the name of the luks2 device. For example, we could use an x-sdbootutil. namespace attribute in /etc/crypttab to registers the ones that will be automatically tracked by sdbootutil. Or enumerate then in the /etc/sysconfig/fdetools file

The problem tracking only cr_* is that is a convention outside the expectation of the users (configuration files and such)

aplanas commented 3 weeks ago

I am experimenting with adding x-sdbootutil.track to mark the encrypted devices that should be tracked by sdbootutil (enroll, unenroll, etc), and seems to be a viable solution.

The problem that I see is the migration. Current systems should manually add this option in /etc/crypttab so the device is recognized by sdbootutil. This is why I am thinking that maybe makes more sense to make is as an opt-out, so adding x-sdbootutil.untrack instead in the devices that sdbootutil should ignore.

What do you think?

aplanas commented 3 weeks ago

https://github.com/openSUSE/sdbootutil/pull/153

TobiPeterG commented 1 week ago

I am experimenting with adding x-sdbootutil.track to mark the encrypted devices that should be tracked by sdbootutil (enroll, unenroll, etc), and seems to be a viable solution.

The problem that I see is the migration. Current systems should manually add this option in /etc/crypttab so the device is recognized by sdbootutil. This is why I am thinking that maybe makes more sense to make is as an opt-out, so adding x-sdbootutil.untrack instead in the devices that sdbootutil should ignore.

What do you think?

I'm slowly getting back on track and working through my different projects :)

Hmm as a user I wouldn't expect my drive to get enrolled, but only the root drive, but that might be me. And now the other PR is already merged, so I guess we will go with this ;) It's fine as well :)

aplanas commented 1 week ago

Hmm as a user I wouldn't expect my drive to get enrolled, but only the root drive, but that might be me.

My expectation is different, but I do not have a good argument to defend it.

But in any case cannot be the root drive only the one managed by sdbootutil. For example, cr_swap should be there too, and in MicroOS I guess etc and var (because of the overlays). I am not sure about cr_home, but is hard for me to argue why sdbootutil should ignore it.

And now the other PR is already merged, so I guess we will go with this ;)

We can change it