[Design implementation] Incorrect ownership and permissions for participation key about go-algorand HOT 3 CLOSED

Yeah, we should clean up the handling of partkeys.

Really, goal shouldn't be directly poking at the data directory, and we should add a REST API for managing partkeys.

In your issue report, where did the algorand group come from? Is this a modified version of the algorand debian package that you've extended along the lines of what you were suggesting in #77? Otherwise, in the default install right now, I don't think users can run goal account addpartkey successfully, because they can't write to /var/lib/algorand.

from go-algorand.

Correct, we had found ourselves aliasing sudo -u algorand goal for all the goal commands, eventually, this causes the state of the install to become unstable. Furthermore, multiple users can see other users' wallets (which is a no-no for us). One particular issue we ran into was that the clerk commands were not seeing an address as multisig (i.e. transactions would not contain msig and signing fails with version not matching 1). So I added the algorand group and added the users to it. This is our stopgap solution to prevent issues with other commands and multiple users stepping over each other.

from go-algorand.

@yaovi-a I believe this can be closed because it is covered by #864 and #1791

from go-algorand.