ranger-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alok Lal (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (RANGER-662) Policy create/update failures leave partial policy in the database
Date Fri, 16 Oct 2015 19:29:05 GMT

     [ 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.
show variables where Variable_name in ('storage_engine', 'table_type');

> 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

View raw message