Eos: Custom Hierarchical Permissions

[marketstack]

goal is to leverage hierarchical permissions in eos

specifically, want to create a new custom permission level in the following structure

owner < active < newpermission

where newpermission can sign a subset of action types e.g. eosio::buyram, but cannot auth any other action type

this way the moderately valuable private key associated with newpermission could be used in a dapp vs the invaluable active / owner keys

does this functionality exist as of right now? it seems that this functionality exists already, specifically i was able to run:

./cleos create key

then take the public key EOS[...] and run:

./cleos set account permission myaccountname newpermission EOS[...] active -p myaccountname@active

this seems to work, meaning it successfully creates a new permission level in the desired hierarchy in that:

./cleos get accounts myaccountname returns new key in hierarchy

permissions:
⋅⋅⋅⋅⋅⋅owner 1: 1 EOS[...]
⋅⋅⋅⋅⋅⋅⋅⋅⋅active 1: 1 EOS[...]
⋅⋅⋅⋅⋅⋅⋅⋅⋅⋅⋅⋅newpermission 1: 1 EOS[...]

now let's say i want the newpermission to only be able to sign action = eosio::buyram:

./cleos set action permission myaccountname eosio buyram newpermission -p myaccountname

i see a linkauth transaction go through without complaint. linkauth is visible in chain explorers

then, however, i create a new wallet and import the private key of newpermission then try to run:

./cleos -system buyram myaccountname myaccountname "0.10 EOS" -p myaccountname@newpermission

and get an error:

Error 3090003: provided keys, permissions, and delays do not satisfy declared authorizations
Ensure that you have the related private keys inside your wallet and your wallet is unlocked.

wallet is def unlocked, so now i'm back to: is this functionality enabled as of now? lol

if not, what needs to be done, i'm game to help this seems like a big one.

if functionality does exist, what have i missed / done wrong in the workflow above?

[abourget]

The default permission for a buyram operation is hard-coded to active. (line 1222 in cleos' main.cpp). Cleos would need to read the -p passed on instead of using the hard-coded one.
I'm rolling out changes to eosc (which is similar to cleos, but cross-platform) that implement that properly for voteproducer and buyram and other actions. It's not as fully-fledged as cleos right now, but already has a few advantages. Take a look http://github.com/eoscanada/eosc

My concern is not being able to see the auth links created through the eosio::linkauth operation.. /v1/chain/get_account doesn't report any such data.. I'd love to see that added. @wanderingbort ?

[marketstack]

thanks for pointing out the hard-coded permission level in cleos! i'm tearing my hair out (whats left that is) with this custom permission so i'm def interested in checking out eosc if it sorts out this custom permission flow business.

custom permissions seem like a big deal to me... i think that it would be a major boon for development on eos if there was a real push to have a majority of users create less valuable sub-keys that linkauth to various subsets of actions

e.g. could have the following custom permission to action mapping:

voter -> voteproducer + regproxy
ramtrader -> buyram + sellram
delegator -> delegatebw + undelegatebw

each sub-key offers a more modular way to secure each action, or group of logically related actions. it also lowers the barrier to marginal user adoption if developers can use named permissions the user has _already_ created to use another dapp

+1 for the comment about /v1/chain/get_account not returning link data, i'd very much like to see that information returned. i've already had it happen where i forgot a linkauth i had pushed already, so this would be great to see it all together.

in the meantime i'm gonna try to get the custom permission to work bypassing cleos and just making POST requests directly to /v1/chain/push_transaction, unless u think there's a better kludge at the moment?

[andresberrios]

@marketstack I'm a bit late to answer this but I think you could try pushing the transaction manually in cleos:

cleos push action eosio buyram '["myaccountname", "myaccountname", "0.1000 EOS"]' -p myaccountname@newpermission

That way you should be able to bypass the hardcoded active permission that was getting injected.

[kesar]

"My concern is not being able to see the auth links created through the eosio::linkauth operation.. /v1/chain/get_account doesn't report any such data.. I'd love to see that added"

+1 👍

Its pretty hard to deleteauth if its linked to unknown permissions. You will get an error where you can parse it and remove one by one, but that's pretty bad

[curiouscat2018]

Any update on this issue ? It would be great if we can see existing linkauth directly from cleos get account. Also, is it possible to view linkauth table directly from cleos ?