[jira] [Created] (SENTRY-2163) Many Instances of DefaultFS Logging Observed
BELUGA BEHR created SENTRY-2163:
---
Summary: Many Instances of DefaultFS Logging Observed
Key: SENTRY-2163
URL: https://issues.apache.org/jira/browse/SENTRY-2163
Project: Sentry
Issue Type: Improvement
Components: Hive Binding
Affects Versions: 1.8.0
Reporter: BELUGA BEHR
https://github.com/apache/sentry/blob/92a183f663c16fc8daf806dcb4a0b264dc811376/sentry-binding/sentry-binding-hive-conf/src/main/java/org/apache/sentry/binding/hive/conf/HiveAuthzConf.java#L180
Seeing many instances of the following in the HiveServer2 log files:
{code}
2018-02-26 07:04:57,318 INFO
org.apache.sentry.binding.hive.conf.HiveAuthzConf: [HiveServer2-Handler-Pool:
Thread-65]: DefaultFS: hdfs://nameservice1
2018-02-26 07:04:57,471 INFO
org.apache.sentry.binding.hive.conf.HiveAuthzConf: [HiveServer2-Handler-Pool:
Thread-65]: DefaultFS: hdfs://nameservice1
2018-02-26 07:04:57,488 INFO
org.apache.sentry.binding.hive.conf.HiveAuthzConf: [HiveServer2-Handler-Pool:
Thread-65]: DefaultFS: hdfs://nameservice1
2018-02-26 07:05:03,430 INFO
org.apache.sentry.binding.hive.conf.HiveAuthzConf: [HiveServer2-Handler-Pool:
Thread-65]: DefaultFS: hdfs://nameservice1
2018-02-26 07:05:03,447 INFO
org.apache.sentry.binding.hive.conf.HiveAuthzConf: [HiveServer2-Handler-Pool:
Thread-65]: DefaultFS: hdfs://nameservice1
2018-02-26 07:05:03,582 INFO
org.apache.sentry.binding.hive.conf.HiveAuthzConf: [HiveServer2-Handler-Pool:
Thread-65]: DefaultFS: hdfs://nameservice1
2018-02-26 07:05:03,599 INFO
org.apache.sentry.binding.hive.conf.HiveAuthzConf: [HiveServer2-Handler-Pool:
Thread-65]: DefaultFS: hdfs://nameservice1
2018-02-26 07:05:44,203 INFO
org.apache.sentry.binding.hive.conf.HiveAuthzConf: [HiveServer2-Handler-Pool:
Thread-65]: DefaultFS: hdfs://nameservice1
2018-02-26 07:05:44,221 INFO
org.apache.sentry.binding.hive.conf.HiveAuthzConf: [HiveServer2-Handler-Pool:
Thread-65]: DefaultFS: hdfs://nameservice1
2018-02-26 07:05:44,364 INFO
org.apache.sentry.binding.hive.conf.HiveAuthzConf: [HiveServer2-Handler-Pool:
Thread-65]: DefaultFS: hdfs://nameservice1
2018-02-26 07:05:44,381 INFO
org.apache.sentry.binding.hive.conf.HiveAuthzConf: [HiveServer2-Handler-Pool:
Thread-65]: DefaultFS: hdfs://nameservice1
2018-02-26 07:05:50,178 INFO
org.apache.sentry.binding.hive.conf.HiveAuthzConf: [HiveServer2-Handler-Pool:
Thread-65]: DefaultFS: hdfs://nameservice1
2018-02-26 07:05:50,200 INFO
org.apache.sentry.binding.hive.conf.HiveAuthzConf: [HiveServer2-Handler-Pool:
Thread-65]: DefaultFS: hdfs://nameservice1
2018-02-26 07:05:50,374 INFO
org.apache.sentry.binding.hive.conf.HiveAuthzConf: [HiveServer2-Handler-Pool:
Thread-65]: DefaultFS: hdfs://nameservice1
2018-02-26 07:05:50,391 INFO
org.apache.sentry.binding.hive.conf.HiveAuthzConf: [HiveServer2-Handler-Pool:
Thread-65]: DefaultFS: hdfs://nameservice1
2018-02-26 07:05:56,715 INFO
org.apache.sentry.binding.hive.conf.HiveAuthzConf: [HiveServer2-Handler-Pool:
Thread-65]: DefaultFS: hdfs://nameservice1
2018-02-26 07:05:56,768 INFO
org.apache.sentry.binding.hive.conf.HiveAuthzConf: [HiveServer2-Handler-Pool:
Thread-65]: DefaultFS: hdfs://nameservice1
2018-02-26 07:05:56,913 INFO
org.apache.sentry.binding.hive.conf.HiveAuthzConf: [HiveServer2-Handler-Pool:
Thread-65]: DefaultFS: hdfs://nameservice1
{code}
I'm not really sure why the same thread is loading so many instances of this
class, but spamming this log message is not helpful. We need to load fewer
instances, lower logging to _debug_, remove the logging altogether, or cache
the _hiveAuthzSiteURL_ and only log the message once per URL instance instead
of once per object instantiation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-1465) truncate table is not working with qualified table names from beeline
[
https://issues.apache.org/jira/browse/SENTRY-1465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380844#comment-16380844
]
BELUGA BEHR commented on SENTRY-1465:
-
[~ychena] Can you confirm that this issue is the same as [SENTRY-1646] and
close this JIRA if that is the case? Thanks.
> truncate table is not working with qualified table names from beeline
> -
>
> Key: SENTRY-1465
> URL: https://issues.apache.org/jira/browse/SENTRY-1465
> Project: Sentry
> Issue Type: Bug
>Affects Versions: 1.5.1
>Reporter: Matyas Orhidi
>Priority: Major
>
> Steps to reproduce the issue:
> {code}
> 0: jdbc:hive2://...> create table temp.a (b int);
> ...
> INFO : OK
> No rows affected (0.163 seconds)
> {code}
> {code}
> 0: jdbc:hive2://...> truncate table temp.a;
> Error: Error while compiling statement: FAILED: SemanticException No valid
> privileges
> User admin does not have privileges for TRUNCATETABLE
> The required privileges: Server=server1->Db=default->Table=temp->action=*;
> (state=42000,code=4)
> {code}
> The user has no privileges in the default database:
> {code}
> 0: jdbc:hive2://...> show current roles;
> +---+--+
> | role |
> +---+--+
> | analyst_role |
> +---+--+
> {code}
> {code}
> 0: jdbc:hive2://...> show grant role analyst_role;
> +---+++-+-+-++---+---+--+--+
> | database | table | partition | column | principal_name |
> principal_type | privilege | grant_option |grant_time | grantor |
> +---+++-+-+-++---+---+--+--+
> | temp ||| | analyst_role| ROLE
> | * | false | 1473206055358000 | -- |
> +---+++-+-+-++---+---+--+--+
> {code}
> A workaround is to add default database privileges to the user
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2134) Apply Hive URI grants recursively to subdirectories
[ https://issues.apache.org/jira/browse/SENTRY-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16363442#comment-16363442 ] BELUGA BEHR commented on SENTRY-2134: - Perhaps, for simplicity sake, Sentry Sync can be keyed off URI alone and no longer on database/table location. Not only is it simple, but it will give flexibility because two tables, within the same database, Sentry can control Hive/Impala access to both but allow only one to be open on HDFS. Finally, there is no need to worry about a database/table location and a URI colliding. > Apply Hive URI grants recursively to subdirectories > --- > > Key: SENTRY-2134 > URL: https://issues.apache.org/jira/browse/SENTRY-2134 > Project: Sentry > Issue Type: Improvement > Components: Hive Binding >Affects Versions: 1.8.0, 2.0.0, 1.7.1 >Reporter: Ruslan Dautkhanov >Priority: Major > Labels: hive, uri > > Currently we need to add direct grants for all Hive tables' LOCATIONs. > Like, 'hdfs_staging/table1', 'hdfs_staging/table2', etc.. > It's not manageable this way. - we can't add grants for each and every table. > It would be great if we could just do one grant - > 'hdfs_staging/' so it would automatically be applied to > 'hdfs_staging/table1', 'hdfs_staging/table2', and other subdirectories. > There is probably a reason this wasn't implemented earlier? Thanks for > considering this improvement. > Also found another user's request on this - > https://community.cloudera.com/t5/Interactive-Short-cycle-SQL/Impala-Sentry-GRANT-ALL-ON-URI-not-cascaded-down-through/td-p/39928 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SENTRY-2134) Apply Hive URI grants recursively to subdirectories
[ https://issues.apache.org/jira/browse/SENTRY-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16358910#comment-16358910 ] BELUGA BEHR commented on SENTRY-2134: - HDFS-Sentry Sync works on DATABASE locations and TABLE locations. URIs are not considered when enforcing HDFS ACLs through Sentry. When a database or table is created, the HDFS-Sentry Sync plugin will automatically apply the appropriate HDFS ACLs for you. There is no need to perform any manual actions. > Apply Hive URI grants recursively to subdirectories > --- > > Key: SENTRY-2134 > URL: https://issues.apache.org/jira/browse/SENTRY-2134 > Project: Sentry > Issue Type: Improvement > Components: Hive Binding >Affects Versions: 1.8.0, 2.0.0, 1.7.1 >Reporter: Ruslan Dautkhanov >Priority: Major > Labels: hive, uri > > Currently we need to add direct grants for all Hive tables' LOCATIONs. > Like, 'hdfs_staging/table1', 'hdfs_staging/table2', etc.. > It's not manageable this way. - we can't add grants for each and every table. > It would be great if we could just do one grant - > 'hdfs_staging/' so it would automatically be applied to > 'hdfs_staging/table1', 'hdfs_staging/table2', and other subdirectories. > There is probably a reason this wasn't implemented earlier? Thanks for > considering this improvement. > Also found another user's request on this - > https://community.cloudera.com/t5/Interactive-Short-cycle-SQL/Impala-Sentry-GRANT-ALL-ON-URI-not-cascaded-down-through/td-p/39928 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SENTRY-2032) Leading Slashes need to removed when creating HMS path entries
[ https://issues.apache.org/jira/browse/SENTRY-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16260714#comment-16260714 ] BELUGA BEHR commented on SENTRY-2032: - Why do we not use https://commons.apache.org/proper/commons-io/javadocs/api-2.5/org/apache/commons/io/FilenameUtils.html#normalize(java.lang.String) ? This way we can have consistent normalization throughout the codebase. > Leading Slashes need to removed when creating HMS path entries > -- > > Key: SENTRY-2032 > URL: https://issues.apache.org/jira/browse/SENTRY-2032 > Project: Sentry > Issue Type: Bug > Components: Sentry >Affects Versions: 2.0.0 >Reporter: Arjun Mishra >Assignee: Arjun Mishra > Fix For: 2.0.0 > > Attachments: SENTRY-2032.01.patch, SENTRY-2032.02.patch, > SENTRY-2032.03.patch, SENTRY-2032.04.patch > > > When retrieving full path image update, we split a path by "/" and create HMS > Path entries. However, the leading "/" presence will cause issues because on > splitting the value at index 0 will be empty. This will affect the creation > of HMS path entries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (SENTRY-1648) Sentry MySQL "Unique" Index
[
https://issues.apache.org/jira/browse/SENTRY-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15905632#comment-15905632
]
BELUGA BEHR edited comment on SENTRY-1648 at 3/10/17 8:06 PM:
--
This is even more important when UTF-8 is being used. {{`URI`(250)}} in UTF-8
is 1000 bytes, way more than will be supported in MySQL or Oracle for index key
length.
Oracle: java.sql.SQLException: ORA-01450: maximum key length (6398) exceeded
was (Author: belugabehr):
This is even more important when UTF-8 is being used. {{`URI`(250)}} in UTF-8
is 1000 bytes, way more than will be supported in MySQL or Oracle for index key
length.
> Sentry MySQL "Unique" Index
> ---
>
> Key: SENTRY-1648
> URL: https://issues.apache.org/jira/browse/SENTRY-1648
> Project: Sentry
> Issue Type: Improvement
>Affects Versions: 1.8.0
>Reporter: BELUGA BEHR
>Priority: Minor
>
> {code:sql|title=sentry-mysql-1.8.0.sql}
> CREATE TABLE `SENTRY_DB_PRIVILEGE` (
> `DB_PRIVILEGE_ID` BIGINT NOT NULL,
> `PRIVILEGE_SCOPE` VARCHAR(32) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
> `SERVER_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
> `DB_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT
> '__NULL__',
> `TABLE_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT
> '__NULL__',
> `COLUMN_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT
> '__NULL__',
> `URI` VARCHAR(4000) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT '__NULL__',
> `ACTION` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
> `CREATE_TIME` BIGINT NOT NULL,
> `WITH_GRANT_OPTION` CHAR(1) NOT NULL
> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
> ALTER TABLE `SENTRY_DB_PRIVILEGE`
> ADD UNIQUE `SENTRY_DB_PRIV_PRIV_NAME_UNIQ`
> (`SERVER_NAME`,`DB_NAME`,`TABLE_NAME`,`COLUMN_NAME`,`URI`(250),`ACTION`,`WITH_GRANT_OPTION`);
> {code}
> As you can see, only the first 250 characters of URI is considered when
> determining "uniqueness". Typically, a second column would be added
> containing the hash value (MD5/SHA) of the URI and that column would instead
> be used as part of the unique index instead of the field itself.
> Oracle would also benefit from this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SENTRY-1648) Sentry MySQL "Unique" Index
[
https://issues.apache.org/jira/browse/SENTRY-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15905632#comment-15905632
]
BELUGA BEHR commented on SENTRY-1648:
-
This is even more important when UTF-8 is being used. {{`URI`(250)}} in UTF-8
is 1000 bytes, way more than will be supported in MySQL or Oracle for index key
length.
> Sentry MySQL "Unique" Index
> ---
>
> Key: SENTRY-1648
> URL: https://issues.apache.org/jira/browse/SENTRY-1648
> Project: Sentry
> Issue Type: Improvement
>Affects Versions: 1.8.0
>Reporter: BELUGA BEHR
>Priority: Minor
>
> {code:sql|title=sentry-mysql-1.8.0.sql}
> CREATE TABLE `SENTRY_DB_PRIVILEGE` (
> `DB_PRIVILEGE_ID` BIGINT NOT NULL,
> `PRIVILEGE_SCOPE` VARCHAR(32) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
> `SERVER_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
> `DB_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT
> '__NULL__',
> `TABLE_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT
> '__NULL__',
> `COLUMN_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT
> '__NULL__',
> `URI` VARCHAR(4000) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT '__NULL__',
> `ACTION` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
> `CREATE_TIME` BIGINT NOT NULL,
> `WITH_GRANT_OPTION` CHAR(1) NOT NULL
> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
> ALTER TABLE `SENTRY_DB_PRIVILEGE`
> ADD UNIQUE `SENTRY_DB_PRIV_PRIV_NAME_UNIQ`
> (`SERVER_NAME`,`DB_NAME`,`TABLE_NAME`,`COLUMN_NAME`,`URI`(250),`ACTION`,`WITH_GRANT_OPTION`);
> {code}
> As you can see, only the first 250 characters of URI is considered when
> determining "uniqueness". Typically, a second column would be added
> containing the hash value (MD5/SHA) of the URI and that column would instead
> be used as part of the unique index instead of the field itself.
> Oracle would also benefit from this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SENTRY-1648) Sentry MySQL "Unique" Index
[
https://issues.apache.org/jira/browse/SENTRY-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BELUGA BEHR updated SENTRY-1648:
Description:
{code:sql|title=sentry-mysql-1.8.0.sql}
CREATE TABLE `SENTRY_DB_PRIVILEGE` (
`DB_PRIVILEGE_ID` BIGINT NOT NULL,
`PRIVILEGE_SCOPE` VARCHAR(32) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`SERVER_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`DB_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT '__NULL__',
`TABLE_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT
'__NULL__',
`COLUMN_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT
'__NULL__',
`URI` VARCHAR(4000) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT '__NULL__',
`ACTION` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`CREATE_TIME` BIGINT NOT NULL,
`WITH_GRANT_OPTION` CHAR(1) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
ALTER TABLE `SENTRY_DB_PRIVILEGE`
ADD UNIQUE `SENTRY_DB_PRIV_PRIV_NAME_UNIQ`
(`SERVER_NAME`,`DB_NAME`,`TABLE_NAME`,`COLUMN_NAME`,`URI`(250),`ACTION`,`WITH_GRANT_OPTION`);
{code}
As you can see, only the first 250 characters of URI is considered when
determining "uniqueness". Typically, a second column would be added containing
the hash value (MD5/SHA) of the URI and that column would instead be used as
part of the unique index instead of the field itself.
Oracle would also benefit from this.
was:
{code:sql|title=sentry-mysql-1.8.0.sql}
CREATE TABLE `SENTRY_DB_PRIVILEGE` (
`DB_PRIVILEGE_ID` BIGINT NOT NULL,
`PRIVILEGE_SCOPE` VARCHAR(32) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`SERVER_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`DB_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT '__NULL__',
`TABLE_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT
'__NULL__',
`COLUMN_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT
'__NULL__',
`URI` VARCHAR(4000) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT '__NULL__',
`ACTION` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`CREATE_TIME` BIGINT NOT NULL,
`WITH_GRANT_OPTION` CHAR(1) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
ALTER TABLE `SENTRY_DB_PRIVILEGE`
ADD UNIQUE `SENTRY_DB_PRIV_PRIV_NAME_UNIQ`
(`SERVER_NAME`,`DB_NAME`,`TABLE_NAME`,`COLUMN_NAME`,`URI`(250),`ACTION`,`WITH_GRANT_OPTION`);
{code}
As you can see, only the first 250 characters of URI is considered when
determining "uniqueness". Typically, a second column would be added containing
the hash value (MD5/SHA) of the URI and that column would instead be used as
part of the unique index instead of the field itself.
Oracle schema does not have this 250 prefix limitation, but maybe it should?
> Sentry MySQL "Unique" Index
> ---
>
> Key: SENTRY-1648
> URL: https://issues.apache.org/jira/browse/SENTRY-1648
> Project: Sentry
> Issue Type: Improvement
>Affects Versions: 1.8.0
>Reporter: BELUGA BEHR
>Priority: Minor
>
> {code:sql|title=sentry-mysql-1.8.0.sql}
> CREATE TABLE `SENTRY_DB_PRIVILEGE` (
> `DB_PRIVILEGE_ID` BIGINT NOT NULL,
> `PRIVILEGE_SCOPE` VARCHAR(32) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
> `SERVER_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
> `DB_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT
> '__NULL__',
> `TABLE_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT
> '__NULL__',
> `COLUMN_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT
> '__NULL__',
> `URI` VARCHAR(4000) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT '__NULL__',
> `ACTION` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
> `CREATE_TIME` BIGINT NOT NULL,
> `WITH_GRANT_OPTION` CHAR(1) NOT NULL
> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
> ALTER TABLE `SENTRY_DB_PRIVILEGE`
> ADD UNIQUE `SENTRY_DB_PRIV_PRIV_NAME_UNIQ`
> (`SERVER_NAME`,`DB_NAME`,`TABLE_NAME`,`COLUMN_NAME`,`URI`(250),`ACTION`,`WITH_GRANT_OPTION`);
> {code}
> As you can see, only the first 250 characters of URI is considered when
> determining "uniqueness". Typically, a second column would be added
> containing the hash value (MD5/SHA) of the URI and that column would instead
> be used as part of the unique index instead of the field itself.
> Oracle would also benefit from this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SENTRY-1648) Sentry MySQL "Unique" Index
BELUGA BEHR created SENTRY-1648:
---
Summary: Sentry MySQL "Unique" Index
Key: SENTRY-1648
URL: https://issues.apache.org/jira/browse/SENTRY-1648
Project: Sentry
Issue Type: Improvement
Affects Versions: 1.8.0
Reporter: BELUGA BEHR
Priority: Minor
{code:sql|title=sentry-mysql-1.8.0.sql}
CREATE TABLE `SENTRY_DB_PRIVILEGE` (
`DB_PRIVILEGE_ID` BIGINT NOT NULL,
`PRIVILEGE_SCOPE` VARCHAR(32) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`SERVER_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`DB_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT '__NULL__',
`TABLE_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT
'__NULL__',
`COLUMN_NAME` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT
'__NULL__',
`URI` VARCHAR(4000) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT '__NULL__',
`ACTION` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`CREATE_TIME` BIGINT NOT NULL,
`WITH_GRANT_OPTION` CHAR(1) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
ALTER TABLE `SENTRY_DB_PRIVILEGE`
ADD UNIQUE `SENTRY_DB_PRIV_PRIV_NAME_UNIQ`
(`SERVER_NAME`,`DB_NAME`,`TABLE_NAME`,`COLUMN_NAME`,`URI`(250),`ACTION`,`WITH_GRANT_OPTION`);
{code}
As you can see, only the first 250 characters of URI is considered when
determining "uniqueness". Typically, a second column would be added containing
the hash value (MD5/SHA) of the URI and that column would instead be used as
part of the unique index instead of the field itself.
Oracle schema does not have this 250 prefix limitation, but maybe it should?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SENTRY-905) Sentry should facilitate some means of authorizing jars outside of Hive's aux jars path
[ https://issues.apache.org/jira/browse/SENTRY-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15838503#comment-15838503 ] BELUGA BEHR commented on SENTRY-905: Is this now enabled by Hive reloadable JARs? > Sentry should facilitate some means of authorizing jars outside of Hive's aux > jars path > --- > > Key: SENTRY-905 > URL: https://issues.apache.org/jira/browse/SENTRY-905 > Project: Sentry > Issue Type: Bug > Components: Sentry >Reporter: Ryan P > > Sentry should add some means to authorize jars outside of hive aux jars. > Currently users need to add jars to the aux path and restart HS2 in order to > use them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
