User secrets return a permission error rather than not found when permissions are missing

[Tony Meyer]

Normally with secrets, I can't tell if the secret doesn't exist or I don't have permission to access it. For example, here this is a valid secret, but the charm only has view permission (the same happens with charm secrets with only view, or with `secret-get` and charm secrets where there's no grant):

```
root@secretconfig-0:/var/lib/juju/agents/unit-secretconfig-0/charm# ../../../tools/unit-secretconfig-0/secret-info-get secret:cpaj0kvmp25c7665757g
ERROR secret "cpaj0kvmp25c7665757g" not found
```

However, with a user secret that the charm doesn't have access to, Juju leaks to me that the secret exists but I don't have permission to see it (if it doesn't exist then I get the expected "not found"):

```
root@secretconfig-0:/var/lib/juju/agents/unit-secretconfig-0/charm# ../../../tools/unit-secretconfig-0/secret-get secret:cpaj0kvmp25c7665757g
ERROR permission denied
```

There is an [ops bug](https://github.com/canonical/operator/issues/1229) for this, but I feel like it should actually change in Juju to be consistent with other secret behaviour.

[Jordan Barrett (barrettj12)]

https://github.com/juju/juju/pull/17467

[Tony Meyer (tony-meyer)]

Steps to reproduce, Juju 3.4.1, microk8s:

```shell
tameyer@tam-canoncial-1:~$ cd scratch/
tameyer@tam-canoncial-1:~/scratch$ mkdir dummycharm
tameyer@tam-canoncial-1:~/scratch$ cd dummycharm/
tameyer@tam-canoncial-1:~/scratch/dummycharm$ charmcraft init --profile=kubernetes
Charmed operator package file and directory tree initialised.

Now edit the following package files to provide fundamental charm metadata
and other information:

charmcraft.yaml
src/charm.py
README.md

tameyer@tam-canoncial-1:~/scratch/dummycharm$ charmcraft pack
Packed dummycharm_ubuntu-22.04-amd64.charm
tameyer@tam-canoncial-1:~/scratch/dummycharm$ juju deploy ./dummycharm_ubuntu-22.04-amd64.charm --resource some-container-image=ghcr.io/canonical/api_demo_server:1.0.1
Located local charm "dummycharm", revision 0
Deploying "dummycharm" from local charm "dummycharm", revision 0 on ubuntu@22.04/stable
tameyer@tam-canoncial-1:~/scratch/dummycharm$ juju add-secret examplesecret one=one
secret:cpfq9b7mp25c77uu93lg
tameyer@tam-canoncial-1:~/scratch/dummycharm$ juju secrets
ID Name Owner Rotation Revision Last updated
cok9ngnmp25c77t3s890 example <model> never 1 2024-04-24
cpfq9b7mp25c77uu93lg examplesecret <model> never 1 2 seconds ago
tameyer@tam-canoncial-1:~/scratch/dummycharm$ juju exec -u dummycharm/0 secret-get secret:cpfq9b7mp25c77uu93lg
ERROR permission denied
ERROR the following task failed:
 - id "174" with return code 1

use 'juju show-task' to inspect the failure

tameyer@tam-canoncial-1:~/scratch/dummycharm$ juju grant-secret examplesecret dummycharm
tameyer@tam-canoncial-1:~/scratch/dummycharm$ juju exec -u dummycharm/0 secret-get secret:cpfq9b7mp25c77uu93lg
one: one
```

[Tony Meyer (tony-meyer)]

Sorry, Juju 3.4.2, not 3.4.1.

[Tony Meyer (tony-meyer)]

Ah, Jordan pointed out that a charm secret behaves the same, and that's true:

```shell
tameyer@tam-canoncial-1:~/scratch/dummycharm$ cat src/charm.py
#!/usr/bin/env python3
# Copyright 2024 Tony Meyer
# See LICENSE file for licensing details.

"""Charm the application."""

import logging

import ops

logger = logging.getLogger(__name__)

class DummycharmCharm(ops.CharmBase):
    """Charm the application."""

    def __init__(self, framework: ops.Framework):
        super().__init__(framework)
        framework.observe(self.on["some_container"].pebble_ready, self._on_pebble_ready)

    def _on_pebble_ready(self, event: ops.PebbleReadyEvent):
        """Handle pebble-ready event."""
        self.unit.add_secret({"two": "two"})
        self.unit.status = ops.ActiveStatus()

if __name__ == "__main__": # pragma: nocover
    ops.main(DummycharmCharm) # type: ignore
tameyer@tam-canoncial-1:~/scratch/dummycharm$ charmcraft pack
Packed dummycharm_ubuntu-22.04-amd64.charm
tameyer@tam-canoncial-1:~/scratch/dummycharm$ juju refresh --path ./dummycharm_ubuntu-22.04-amd64.charm dummycharm
Added local charm "dummycharm", revision 1, to the model
tameyer@tam-canoncial-1:~/scratch/dummycharm$ juju add-unit dummycharm
tameyer@tam-canoncial-1:~/scratch/dummycharm$ juju secrets
ID Name Owner Rotation Revision Last updated
cpfq9b7mp25c77uu93lg examplesecret <model> never 1 26 minutes ago
cpfqlgvmp25c77lna7h0 - dummycharm/0 never 1 14 seconds ago
cpfqlinmp25c77lna7hg - dummycharm/1 never 1 7 seconds ago
tameyer@tam-canoncial-1:~/scratch/dummycharm$ juju exec -u dummycharm/0 secret-get secret:cpfqlgvmp25c77lna7h0
two: two
tameyer@tam-canoncial-1:~/scratch/dummycharm$ juju exec -u dummycharm/1 secret-get secret:cpfqlgvmp25c77lna7h0
ERROR permission denied
ERROR the following task failed:
 - id "180" with return code 1

use 'juju show-task' to inspect the failure
```

There is inconsistency between secret-get and secret-info-get (and maybe elsewhere), e.g.:

```shell
tameyer@tam-canoncial-1:~/scratch/dummycharm$ juju exec -u dummycharm/0 secret-info-get cpfq9b7mp25c77uu93lg
ERROR secret "cpfq9b7mp25c77uu93lg" not found
ERROR the following task failed:
 - id "184" with return code 1

use 'juju show-task' to inspect the failure

tameyer@tam-canoncial-1:~/scratch/dummycharm$ juju exec -u dummycharm/0 secret-info-get cpfqlgvmp25c77lna7h0
cpfqlgvmp25c77lna7h0:
  revision: 1
  label: ""
  owner: unit
  rotation: never
tameyer@tam-canoncial-1:~/scratch/dummycharm$ juju exec -u dummycharm/1 secret-info-get cpfqlgvmp25c77lna7h0
ERROR secret "cpfqlgvmp25c77lna7h0" not found
ERROR the following task failed:
 - id "188" with return code 1

use 'juju show-task' to inspect the failure

tameyer@tam-canoncial-1:~/scratch/dummycharm$

```

But there too user and charm secrets are the same.

I'll re-open the ops bug and open a PR to fix ops. If you want to make the various cases consistent that would still be nice, but the user vs charm case seems to be ...

[Jordan Barrett (barrettj12)]

Marking as invalid since the bug as originally written is not reproducible.

We have agreed that
- If one attempts to access a secret that doesn't exist, Juju should return "not found"
- If one attempts to access a secret that does exist, but which they don't have permission to access, Juju should return "permission denied"

If the inconsistency between different hook tools is causing friction for ops, feel free to open a new bug.