Add pre-check for user permissions before sending command to salt-api

[arthurzenika]

At some point in testing, I was quite surprised to find :

$ pepper -H -v '*' cmd.run 'whoami'
{u'perms': [u'test.ping'], u'start': 1422612427.829301, u'token': u'318dec9ad3007ccbc978f2dea72bf285e0b0f8ae', u'expire': 1422655627.829302, u'user': u'saltdev', u'eauth': u'pam'}
{u'return': [{u'jid': u'20150130110707846297', u'minions': [u'ursa', u'cetus.logilab.priv']}]}
{
    "cetus.logilab.priv": "root", 
    "ursa": "root"
}

Investigating further made me understand that the one enforcing the policy was salt-master and since I had not restarted the salt-master (but only salt-api) between changing from '.*' to 'test.ping' in the external_auth, it would return results for a cmd.run query.

Could I argue that every intermediary (pepper or any webapp and salt-api) should look at the permissions before trying to run them ? Is this what was meant for when returning the "perms" information when on logs in ?

Am heading to salt issue tracker to add an issue for this one as well.

[whiteinge]

The perms return after logging in is intended for consumption by clients of the REST API so they can provide a more user-friendly experience. It is decidedly not intended for any kind of security.

As a real-world example, a web UI could use the perms output to only display or auto-complete function names the current user has permission to run. It makes sense to add something similar to Pepper (probably requiring #4). That would allow Pepper to quickly perform a pre-flight check before sending any comparatively slow HTTP requests only to arrive at the same 'denied' answer.

I am marking this as a feature addition and will edit the issue title to coincide.