Proposed use case: Readonly Store #1892
Conversation
82ea533 to
895f024
Compare
Initial version of use case proposal: Readyonly Store RELEASE_NOTES=[DOCUMENTATION] Signed-off-by: morningspace <morningspace@yahoo.com>
| $ gopass config readonly true | ||
| readonly: true | ||
| # To apply the config to a sub-store | ||
| $ gopass config readly true --store team-sharable |
There was a problem hiding this comment.
This should read gopass config readonly.
But I don't think I want to bring back nested configs. They were very painful.
There needs to be a better way.
There was a problem hiding this comment.
My bad, let me fix it. Re: nested configs, do you mean the per-store config? I wonder why that's painful. Understand that can introduce complexity such as the possible conflict between per-store config and global config.
|
|
||
| Ultimately it turns out that this scenario requires a feature such as a store in readonly mode, where people can configure their local store or a set of sub-stores in readonly mode, to disable the writes and the autosync-on-writes to the store, but they can still pull to sync the latest changes from the remote store. This is not a one-stop solution for the RBAC model of the team sharing store, because we still need GitHub to setup the store access at server-side, but it will provide better usage experience from gopass client side. | ||
|
|
||
| Configuration examples: |
There was a problem hiding this comment.
I'm not convinced this is the best way to do it, yet.
Maybe we should drop the Configuration examples section and have a more open ended Usage examples one?
There was a problem hiding this comment.
Sure, I'm open to make any change as long as it can address the issue nicely.
Yeah, I hope so too. Right now, I am not sure whether there's simpler option. If we consider this as a configurable thing, then I think no matter what name it is, readonly, offline, or whatever else, it is essentially a way to control the writes and autosync-on-writes behavior conditionally. Also, it seems that has to be a per-store config, because practically, to make the local store completely readonly is not a good idea as people may have both private and sharable stuff stored on local. On the other side, if we can consider it as a non-configurable thing, maybe a better idea, since people can explicitly turn off the readonly config for a team sharing store which will bring back the painful things again. With that, it looks to declare a store to be readonly during the init phase would make much more sense. However, the store owners or privileged users still need write access to the store. This makes the idea slip to some kind of RBAC model which is also something I may want to avoid since it may also be complex or even more complex than a config option. |
|
I'd still want to merge this and eventually support the use case but I don't like to proposed configuration section, yet. So either @morningspace changes this or we merge it as is and update it afterwards. |
|
@dominikschulz I think you can edit it by sending extra commits directly on the branch morningspace/gopass, and it will accept commits from the original repo maintainers. |
Background of this use case, see: #1878.