You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ranger.apache.org by "Endre Kovacs (JIRA)" <ji...@apache.org> on 2017/12/01 14:37:00 UTC

[jira] [Comment Edited] (RANGER-1643) Handle multiple comma in credentials ...

    [ https://issues.apache.org/jira/browse/RANGER-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16274330#comment-16274330 ] 

Endre Kovacs edited comment on RANGER-1643 at 12/1/17 2:36 PM:
---------------------------------------------------------------

[~bpatel] [~sneethiraj] [~rdonbosco]

i've got a observation / question / suggestion:

Currently each service service definition is (re)using exactly the same:
* encryption algorithm
* encryption key
* salt
* number of iterations

that is stored in `security-admin/src/main/resources/conf.dist/ranger-admin-default-site.xml`:
{code}
        <!-- Encryption -->
       <property>
               <name>ranger.password.encryption.key</name>
               <value>tzL1AKl5uc4NKYaoQ4P3WLGIBFPXWPWdu1fRm9004jtQiV</value>
       </property>
       <property>
               <name>ranger.password.salt</name>
               <value>f77aLYLo</value>
       </property>
       <property>
               <name>ranger.password.iteration.count</name>
               <value>1000</value>
       </property>
       <property>
               <name>ranger.password.encryption.algorithm</name>
               <value>PBEWithMD5AndDES</value>
       </property>
{code}

IMHO at least _encryption key_ and _salt_ should be moved out from this shared config area (but preferably iteration and algo as well), and introduced under the config node at each `ranger-servicedef-<SERVICENAME>.json` OR generated and set to the field `org.apache.ranger.plugin.model.RangerService.configs` on the fly  when the service is created, 
as new key and value pairs.

For services created after this change would use the updated servicedef json files.
How ever I believe for existing ranger services, migration to this new service "schema" will be necessary. However i will need some guidance on how to contribute such migration code for existing servicedefs.

Best regards,
Endre


was (Author: andrewsmith87):
[~bpatel] [~sneethiraj] [~rdonbosco]

i've got a observation / question / suggestion:

Currently each service service definition is (re)using exactly the same:
* encryption algorithm
* encryption key
* salt
* number of iterations

that is stored in `security-admin/src/main/resources/conf.dist/ranger-admin-default-site.xml`:
{code}
        <!-- Encryption -->
       <property>
               <name>ranger.password.encryption.key</name>
               <value>tzL1AKl5uc4NKYaoQ4P3WLGIBFPXWPWdu1fRm9004jtQiV</value>
       </property>
       <property>
               <name>ranger.password.salt</name>
               <value>f77aLYLo</value>
       </property>
       <property>
               <name>ranger.password.iteration.count</name>
               <value>1000</value>
       </property>
       <property>
               <name>ranger.password.encryption.algorithm</name>
               <value>PBEWithMD5AndDES</value>
       </property>
{code}

IMHO at least _encryption key_ and _salt_ should be moved out from this shared config area (but preferably iteration and algo as well), and introduced under the config node at each `ranger-servicedef-<SERVICENAME>.json` OR generated and set to the field `org.apache.ranger.plugin.model.RangerService.configs` on the fly  when the service is created, 
as new key and value pairs.

Best regards,
Endre

> Handle multiple comma in credentials ...
> ----------------------------------------
>
>                 Key: RANGER-1643
>                 URL: https://issues.apache.org/jira/browse/RANGER-1643
>             Project: Ranger
>          Issue Type: Bug
>          Components: Ranger
>    Affects Versions: 0.6.3, 0.7.1
>            Reporter: Selvamohan Neethiraj
>            Assignee: Endre Kovacs
>            Priority: Minor
>             Fix For: 1.0.0
>
>
> Currently, PasswordUtils parses the encryption configuration based on the presence of a comma character. The actual password itself may have comma characters. We should fix this to allow the user with the password or we should remove the code that handles the password without having encryption configuration as part of the input string.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)