You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ranger.apache.org by "Alok Lal (JIRA)" <ji...@apache.org> on 2015/09/24 06:54:04 UTC

[jira] [Created] (RANGER-662) Policy create/update failures leave partial policy in the database

Alok Lal created RANGER-662:
-------------------------------

             Summary: Policy create/update failures leave partial policy in the database
                 Key: RANGER-662
                 URL: https://issues.apache.org/jira/browse/RANGER-662
             Project: Ranger
          Issue Type: Bug
          Components: admin
    Affects Versions: 0.5.0
            Reporter: Alok Lal
            Priority: Critical
             Fix For: 0.5.1, 0.6.0


Create a policy payload per the v1 public API such that it contains an invalid/non-existent usergroup.  Do a POST to create a new policy with such a faulty payload.  Server returns 400 back to the caller (per the access log).  However, a policy gets created.  Further policy has as all of the policy items in it before it encountered the one that had the faulty group in it.  In fact, if the offending policy item had, say, 3 groups in it and the last one is bad then even that policy item is created with 2 correct user groups!

The same is true if a PUT is done to an existing policy, i.e. existing policy items are deleted and all policy items before the one with bad user group get added and 400 is returned to the caller.

Expectation is that either all of non of the policy changes should get persisted.  Unless we return 2xx policy should not get created/updated.

Here is an example payload.
{code}
{
  "repositoryName": "hivedev",
  "repositoryType": "hive",
  "databases": "*",
  "tables": "*",
  "columns": "*",
  "permMapList": [
    {
      "groupList": [ "hrt_1", "hadoop", "foobar" ],
      "permList": [ "Select" ],
      "userList": []
    }
  ],
 "policyName": "Test_policy_aruna"
}
{code}

I have not tried this with directly going against the new API.  But it would be worth confirming that, too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)