Plugin deregister always reports it succeeds but actually fails.

[joel-rieke]

Describe the bug
Deregistering a plugin that has either been corrupted, removed, overwritten fails.... It seems there either ought to be a --force option for deregister or it should succeed at being removed.

To Reproduce
Steps to reproduce the behavior:

1. Manually delete a plugin from the plugin folder when vault is offline..
2. Run the usual:
   vault secret disable...
   vault plugin deregister
3. vault plugin list
   -- Notice plugin is still in the list!!

Expected behavior
plugin should be deregistered...

Environment:

• Vault Server Version (retrieve with vault status):
• Key Value

---

Seal Type shamir
Initialized true
Sealed false
Total Shares 1
Threshold 1
Version 1.3.6
Cluster Name vault-cluster-
Cluster ID
HA Enabled false

• Vault CLI Version (retrieve with vault version):
  Vault v1.3.6

• Server Operating System/Architecture:
  Linux ...-microsoft-standard-WSL2 ..1 SMP Wed Nov 23 01:01:46 UTC 2022 x86_64 GNU/Linux

Vault server configuration file(s):
kind of irrelevant although most relevant part is probably...

storage "file" {
  path    = "./vault/data"
}
<redacted>....
plugin_directory = "/home/<redacted>/plugins/"

**Additional context**
This is a dev environment...

[hsimon-hashicorp]

Hello! Could you let us know more about what you mean by "while vault is offline"? Is the process not running at all, or is Vault in a sealed state? If you could provide more detailed repro steps, I'd appreciate it.

[joel-rieke]

Thanks. It is not running and it is sealed. It's been awhile since I filed this so remembering more details could be a challenge. But it may have come down to permissions on linux. Also, this is probably most likely to affect a plugin developer developing things locally as they are getting started maybe?

1. Run vault as user x (in my case it might have been root or sudo).
2. Register plugin as user x.
3. Come back some other day and run vault as user y (non root).
4. Deregister plugin with vault running as user y.
   -- I think at this point it appears to have 'deleted' it... but it didn't
5. Manually deleting it from the plugin dir also doesn't work (for obvious reasons).

Expected:
What I really think is that Vault should recognize what's going on and report that it is unable to actually deregister the plugin for permissions reasons. As a newer plugin developer it was pretty confusing and took me awhile to figure out what was going on.

Workaround:
As sudo do some manual cleanup and permissions changing in the data directory (I shouldn't ever do this, but I'm a developer and like to hack, so I did)

Other observations:
I noticed the data directory can get into interesting mixed permissions state which is probably not good for Vault's inner working states.

[joel-rieke]

Closing since this must have been a self imposed issue.