base-sim: don't allow sending PIN/PUK if not required

This avoids issues when e.g. sending SIM-PIN while the modem is
already unlocked or when SIM-PIN is not enabled.

Under those conditions, the needlessly sent SIM-PIN unlock attempt may
fail while libmm-glib/mmcli reports a successful operation. E.g.:

  # mmcli --sim=/org/freedesktop/ModemManager1/SIM/0 --pin=3497
  successfully sent PIN code to the SIM

But in reality...

  Wed Nov 20 14:38:52 2019 daemon.debug [4254]: <debug> [1574260732.489513] Verifying PIN...
  Wed Nov 20 14:38:52 2019 daemon.debug [4254]: [/dev/cdc-wdm0] sent message...
  <<<<<< RAW:
  <<<<<<   length = 27
  <<<<<<   data   = 01:1A:00:00:0B:02:00:09:00:26:00:0E:00:02:06:00:01:04:33:34:39:37:01:02:00:06:00
  Wed Nov 20 14:38:52 2019 daemon.debug [4254]: [/dev/cdc-wdm0] sent generic request (translated)...
  <<<<<< QMUX:
  <<<<<<   length  = 26
  <<<<<<   flags   = 0x00
  <<<<<<   service = "uim"
  <<<<<<   client  = 2
  <<<<<< QMI:
  <<<<<<   flags       = "none"
  <<<<<<   transaction = 9
  <<<<<<   tlv_length  = 14
  <<<<<<   message     = "Verify PIN" (0x0026)
  <<<<<< TLV:
  <<<<<<   type       = "Info" (0x02)
  <<<<<<   length     = 6
  <<<<<<   value      = 01:04:33:34:39:37
  <<<<<<   translated = [ pin_id = 'pin1' pin_value = '3497' ]
  Wed Nov 20 14:38:52 2019 daemon.debug [4254]: [/dev/cdc-wdm0] received message...
  <<<<<< RAW:
  <<<<<<   length = 30
  <<<<<<   data   = 01:1D:00:80:0B:02:02:09:00:26:00:11:00:02:04:00:01:00:52:00:13:02:00:69:84:10:02:00:03:0A
  Wed Nov 20 14:38:52 2019 daemon.debug [4254]: [/dev/cdc-wdm0] received generic response (translated)...
  <<<<<< QMUX:
  <<<<<<   length  = 29
  <<<<<<   flags   = 0x80
  <<<<<<   service = "uim"
  <<<<<<   client  = 2
  <<<<<< QMI:
  <<<<<<   flags       = "response"
  <<<<<<   transaction = 9
  <<<<<<   tlv_length  = 17
  <<<<<<   message     = "Verify PIN" (0x0026)
  <<<<<< TLV:
  <<<<<<   type       = "Result" (0x02)
  <<<<<<   length     = 4
  <<<<<<   value      = 01:00:52:00
  <<<<<<   translated = FAILURE: AccessDenied

As we already know what the current lock status is, just abort the
user operation if the unlock operation isn't required.
1 file changed