[ 
https://issues.apache.org/jira/browse/RANGER-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alok Lal resolved RANGER-662.
-----------------------------
    Resolution: Not A Problem

[~madhan.neethiraj] found the root cause.  Mysql database was configured to use 
a non-transactional database (in this particular case it was using {{MyISAM}} 
instead of, say, {{InnoDB}}).  The problem cannot be reproduced in a database 
that uses {{InnoDB}} engine.

Following could be used to quickly confirm.
{code}
show variables where Variable_name in ('storage_engine', 'table_type');
{code}

> 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
>            Assignee: 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)

Reply via email to