On Mon, Jan 24, 2022 at 7:21 PM Alasdair G Kergon <agk@xxxxxxxxxx> wrote: > > On Mon, Jan 24, 2022 at 10:25:47AM -0500, Brian Geffon wrote: > > Thank you for looking at this. There are a few reasons this might be > > useful, the first is if you're trying to speed up a graceful teardown > > of the device by informing userspace that this device is going to be > > removed in the near future. Another might be on systems where it might > > be worthwhile to not have users with CAP_DAC_OVERRIDE be able to open > > the device. The logic on this second case is that, suppose you have a > > dm-crypt block device which is backing swap, the data on this device > > is ephemeral so a flow might be to setup swap followed by dmsetup > > remove --deferred /dev/mapper/encrypted-swap. This will guarantee that > > as soon as swap is torn down the encrypted block device is dropped, > > additionally with this new flag you'll be guaranteed that there can be > > no further opens on it. > > And is that the reason you propose this? > - You want a special exclusive 'one time open' device that > self-destructs when closed? > > > No, this is fully backwards compatible with the current deferred > > remove behavior, it's not required. Additionally, since on the actual > > remove userspace would receive an -ENXIO already once the remove > > process has started it seems reasonable to return -ENXIO in the > > deferred remove case when this flag is enabled. > > Well I feel it does break existing semantics which is why we wrote > the code the way we did. The state can be long-lived, the code > that has it open might legitimately want to open it again in > parallel etc. - in general this seems a bad idea. > > But if the reason for this is basically "make it harder for > anything else to access my encrypted swap" and to deliberately > prevent access, then let's approach the requirement from that angle. > Are there alternative implementations with interventions at different > points? I was thinking perhaps another implementation might involve using open_count on dm_ioctl as an in param on DM_DEV_CREATE only. Using open_count as an in parameter on DM_DEV_CREATE could be activated by a new flag, perhaps DM_ENFORCE_OPEN_COUNT_FLAG. This would allow the behavior to be baked into the device from the start. We would then enforce it in dm_blk_open. What would you think about an approach like this? Thanks, Brian -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
