[jira] [Updated] (SENTRY-1546) Generic Policy provides bad error messages for Sentry exceptions
[
https://issues.apache.org/jira/browse/SENTRY-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Kolbasov updated SENTRY-1546:
---
Fix Version/s: sentry-ha-redesign
> Generic Policy provides bad error messages for Sentry exceptions
>
>
> Key: SENTRY-1546
> URL: https://issues.apache.org/jira/browse/SENTRY-1546
> Project: Sentry
> Issue Type: Bug
>Affects Versions: 1.8.0, sentry-ha-redesign
>Reporter: Alexander Kolbasov
>Assignee: kalyan kumar kalvagadda
>Priority: Minor
> Labels: bite-sized
> Fix For: 1.8.0, sentry-ha-redesign
>
> Attachments: SENTRY-1546.001.patch,
> SENTRY-1546.001-sentry-ha-redesign.patch, SENTRY-1546.002.patch,
> SENTRY-1546.003.patch, SENTRY-1546.005.patch
>
>
> I discovered that when you attempt to create a role that already exists the
> error message you get back from Thrift i just 'Role: foo' which is very
> confusing.
> The reason is that the SentryStore throws
> {code}SentryAlreadyExistsException("Role: " + trimmedRoleName);{code}
> and the generic policy processor passes the message as is:
> {code}
> public TCreateSentryRoleResponse create_sentry_role(
> final TCreateSentryRoleRequest request) throws TException {
> Response respose = requestHandle(new RequestHandler() {
> @Override
> public Response handle() throws Exception {
> validateClientVersion(request.getProtocol_version());
> authorize(request.getRequestorUserName(),
> getRequestorGroups(conf, request.getRequestorUserName()));
> store.createRole(request.getComponent(), request.getRoleName(),
> request.getRequestorUserName());
> return new Response(Status.OK());
> }
> });
> ...
> {code}
> The similar thing is happening for other requests and other Sentry-specific
> exceptions.
> The legacy policy processor does decorate the error a bit:
> {code}
> public TCreateSentryRoleResponse create_sentry_role(
> TCreateSentryRoleRequest request) throws TException {
> final Timer.Context timerContext = sentryMetrics.createRoleTimer.time();
> TCreateSentryRoleResponse response = new TCreateSentryRoleResponse();
> try {
> validateClientVersion(request.getProtocol_version());
> authorize(request.getRequestorUserName(),
> getRequestorGroups(request.getRequestorUserName()));
> sentryStore.createSentryRole(request.getRoleName());
> response.setStatus(Status.OK());
> notificationHandlerInvoker.create_sentry_role(request, response);
> } catch (SentryAlreadyExistsException e) {
> String msg = "Role: " + request + " already exists.";
> LOGGER.error(msg, e);
> response.setStatus(Status.AlreadyExists(msg, e));
> } catch (SentryAccessDeniedException e) {
> LOGGER.error(e.getMessage(), e);
> response.setStatus(Status.AccessDenied(e.getMessage(), e));
> } catch (SentryThriftAPIMismatchException e) {
> LOGGER.error(e.getMessage(), e);
> response.setStatus(Status.THRIFT_VERSION_MISMATCH(e.getMessage(), e));
> } catch (Exception e) {
> String msg = "Unknown error for request: " + request + ", message: " +
> e.getMessage();
> LOGGER.error(msg, e);
> response.setStatus(Status.RuntimeError(msg, e));
> } finally {
> ...
> {code}
> I think that it is better to just put the right message in the exception
> itself and do not decorate it later.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SENTRY-1646) Unable to truncate table .; from "default" databases
[
https://issues.apache.org/jira/browse/SENTRY-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15898542#comment-15898542
]
Hadoop QA commented on SENTRY-1646:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12856322/SENTRY-1646.1.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/2406/console
This message is automatically generated.
> Unable to truncate table .; from "default" databases
> -
>
> Key: SENTRY-1646
> URL: https://issues.apache.org/jira/browse/SENTRY-1646
> Project: Sentry
> Issue Type: Bug
> Components: Hive Plugin
>Affects Versions: 1.7.0
>Reporter: Eric Lin
>Assignee: Yongzhi Chen
>Priority: Critical
> Attachments: SENTRY-1646.1.patch
>
>
> When the user is doing truncate table .; from "default"
> databases, it throws below error :
> {code}
> 0: jdbc:hive2://localhost:1/default> truncate table test.test;
> Error: Error while compiling statement: FAILED: SemanticException No valid
> privileges
> User user1 does not have privileges for TRUNCATETABLE
> The required privileges: Server=server1->Db=default->Table=test->action=*;
> (state=42000,code=4)
> {code}
> It works if user does "use database;" and then runs truncate table:
> {code}
> 0: jdbc:hive2://localhost:1/default> use test;
> INFO : Compiling
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41):
> use test
> INFO : Semantic Analysis Completed
> INFO : Returning Hive schema: Schema(fieldSchemas:null, properties:null)
> INFO : Completed compiling
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41);
> Time taken: 0.128 seconds
> INFO : Executing
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41):
> use test
> INFO : Starting task [Stage-0:DDL] in serial mode
> INFO : Completed executing
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41);
> Time taken: 0.014 seconds
> INFO : OK
> No rows affected (0.201 seconds)
> 0: jdbc:hive2://localhost:1/default> truncate table test.test;
> INFO : Compiling
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1):
> truncate table test.test
> INFO : Semantic Analysis Completed
> INFO : Returning Hive schema: Schema(fieldSchemas:null, properties:null)
> INFO : Completed compiling
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1);
> Time taken: 0.111 seconds
> INFO : Executing
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1):
> truncate table test.test
> INFO : Starting task [Stage-0:DDL] in serial mode
> INFO : Completed executing
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1);
> Time taken: 0.046 seconds
> INFO : OK
> No rows affected (0.179 seconds)
> 0: jdbc:hive2://localhost:1/default>
> {code}
> The workaround is to grant user permissions to the current data, then the
> issue will go away.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SENTRY-1388) Make HiveConf and Hive client jars available to Sentry deamon
[ https://issues.apache.org/jira/browse/SENTRY-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsee Yarlagadda updated SENTRY-1388: -- Attachment: SENTRY-1388.01-sentry-ha-redesign.patch > Make HiveConf and Hive client jars available to Sentry deamon > - > > Key: SENTRY-1388 > URL: https://issues.apache.org/jira/browse/SENTRY-1388 > Project: Sentry > Issue Type: Sub-task > Components: Hdfs Plugin >Affects Versions: sentry-ha-redesign >Reporter: Colin P. McCabe >Assignee: Vamsee Yarlagadda > Fix For: sentry-ha-redesign > > Attachments: SENTRY-1388.01-sentry-ha-redesign.patch > > > The Sentry daemon should be able to make RPCs to Hive. This involves > modifying the sentry script to have the right CLASSPATH entries. It may also > involve solving some Maven dependency issues. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SENTRY-1639) Refactor thrift clients configuration constants
[ https://issues.apache.org/jira/browse/SENTRY-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15898447#comment-15898447 ] kalyan kumar kalvagadda commented on SENTRY-1639: - This change is applicable for master as well. I initially though master needs other commits before this change set but that is not the case. > Refactor thrift clients configuration constants > --- > > Key: SENTRY-1639 > URL: https://issues.apache.org/jira/browse/SENTRY-1639 > Project: Sentry > Issue Type: Improvement > Components: Sentry >Reporter: kalyan kumar kalvagadda >Assignee: kalyan kumar kalvagadda > Attachments: SENTRY-1639.001-sentry-ha-redesign.patch, > SENTRY-1639.002-sentry-ha-redesign.patch > > > This task is aimed at abstracting the configuration constants and expose an > interface which application logic could use to get appropriate configuration > value from a configuration file provided. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SENTRY-1639) Refactor thrift clients configuration constants
[ https://issues.apache.org/jira/browse/SENTRY-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15898439#comment-15898439 ] Alexander Kolbasov commented on SENTRY-1639: [~kkalyan] This change seems to be generic and applicable to master as well - is there any reason you want to limit it to sentry-ha-redesign branch? > Refactor thrift clients configuration constants > --- > > Key: SENTRY-1639 > URL: https://issues.apache.org/jira/browse/SENTRY-1639 > Project: Sentry > Issue Type: Improvement > Components: Sentry >Reporter: kalyan kumar kalvagadda >Assignee: kalyan kumar kalvagadda > Attachments: SENTRY-1639.001-sentry-ha-redesign.patch, > SENTRY-1639.002-sentry-ha-redesign.patch > > > This task is aimed at abstracting the configuration constants and expose an > interface which application logic could use to get appropriate configuration > value from a configuration file provided. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SENTRY-1646) Unable to truncate table .; from "default" databases
[
https://issues.apache.org/jira/browse/SENTRY-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15898426#comment-15898426
]
Hao Hao commented on SENTRY-1646:
-
[~ychena] submitted it, would you mind to create a code review for it? Thanks!
> Unable to truncate table .; from "default" databases
> -
>
> Key: SENTRY-1646
> URL: https://issues.apache.org/jira/browse/SENTRY-1646
> Project: Sentry
> Issue Type: Bug
> Components: Hive Plugin
>Affects Versions: 1.7.0
>Reporter: Eric Lin
>Assignee: Yongzhi Chen
>Priority: Critical
> Attachments: SENTRY-1646.1.patch
>
>
> When the user is doing truncate table .; from "default"
> databases, it throws below error :
> {code}
> 0: jdbc:hive2://localhost:1/default> truncate table test.test;
> Error: Error while compiling statement: FAILED: SemanticException No valid
> privileges
> User user1 does not have privileges for TRUNCATETABLE
> The required privileges: Server=server1->Db=default->Table=test->action=*;
> (state=42000,code=4)
> {code}
> It works if user does "use database;" and then runs truncate table:
> {code}
> 0: jdbc:hive2://localhost:1/default> use test;
> INFO : Compiling
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41):
> use test
> INFO : Semantic Analysis Completed
> INFO : Returning Hive schema: Schema(fieldSchemas:null, properties:null)
> INFO : Completed compiling
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41);
> Time taken: 0.128 seconds
> INFO : Executing
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41):
> use test
> INFO : Starting task [Stage-0:DDL] in serial mode
> INFO : Completed executing
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41);
> Time taken: 0.014 seconds
> INFO : OK
> No rows affected (0.201 seconds)
> 0: jdbc:hive2://localhost:1/default> truncate table test.test;
> INFO : Compiling
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1):
> truncate table test.test
> INFO : Semantic Analysis Completed
> INFO : Returning Hive schema: Schema(fieldSchemas:null, properties:null)
> INFO : Completed compiling
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1);
> Time taken: 0.111 seconds
> INFO : Executing
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1):
> truncate table test.test
> INFO : Starting task [Stage-0:DDL] in serial mode
> INFO : Completed executing
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1);
> Time taken: 0.046 seconds
> INFO : OK
> No rows affected (0.179 seconds)
> 0: jdbc:hive2://localhost:1/default>
> {code}
> The workaround is to grant user permissions to the current data, then the
> issue will go away.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (SENTRY-1646) Unable to truncate table .; from "default" databases
[
https://issues.apache.org/jira/browse/SENTRY-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hao Hao reassigned SENTRY-1646:
---
Assignee: Yongzhi Chen
> Unable to truncate table .; from "default" databases
> -
>
> Key: SENTRY-1646
> URL: https://issues.apache.org/jira/browse/SENTRY-1646
> Project: Sentry
> Issue Type: Bug
> Components: Hive Plugin
>Affects Versions: 1.7.0
>Reporter: Eric Lin
>Assignee: Yongzhi Chen
>Priority: Critical
> Attachments: SENTRY-1646.1.patch
>
>
> When the user is doing truncate table .; from "default"
> databases, it throws below error :
> {code}
> 0: jdbc:hive2://localhost:1/default> truncate table test.test;
> Error: Error while compiling statement: FAILED: SemanticException No valid
> privileges
> User user1 does not have privileges for TRUNCATETABLE
> The required privileges: Server=server1->Db=default->Table=test->action=*;
> (state=42000,code=4)
> {code}
> It works if user does "use database;" and then runs truncate table:
> {code}
> 0: jdbc:hive2://localhost:1/default> use test;
> INFO : Compiling
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41):
> use test
> INFO : Semantic Analysis Completed
> INFO : Returning Hive schema: Schema(fieldSchemas:null, properties:null)
> INFO : Completed compiling
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41);
> Time taken: 0.128 seconds
> INFO : Executing
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41):
> use test
> INFO : Starting task [Stage-0:DDL] in serial mode
> INFO : Completed executing
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41);
> Time taken: 0.014 seconds
> INFO : OK
> No rows affected (0.201 seconds)
> 0: jdbc:hive2://localhost:1/default> truncate table test.test;
> INFO : Compiling
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1):
> truncate table test.test
> INFO : Semantic Analysis Completed
> INFO : Returning Hive schema: Schema(fieldSchemas:null, properties:null)
> INFO : Completed compiling
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1);
> Time taken: 0.111 seconds
> INFO : Executing
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1):
> truncate table test.test
> INFO : Starting task [Stage-0:DDL] in serial mode
> INFO : Completed executing
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1);
> Time taken: 0.046 seconds
> INFO : OK
> No rows affected (0.179 seconds)
> 0: jdbc:hive2://localhost:1/default>
> {code}
> The workaround is to grant user permissions to the current data, then the
> issue will go away.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SENTRY-1646) Unable to truncate table .; from "default" databases
[
https://issues.apache.org/jira/browse/SENTRY-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hao Hao updated SENTRY-1646:
Status: Patch Available (was: Open)
> Unable to truncate table .; from "default" databases
> -
>
> Key: SENTRY-1646
> URL: https://issues.apache.org/jira/browse/SENTRY-1646
> Project: Sentry
> Issue Type: Bug
> Components: Hive Plugin
>Affects Versions: 1.7.0
>Reporter: Eric Lin
>Priority: Critical
> Attachments: SENTRY-1646.1.patch
>
>
> When the user is doing truncate table .; from "default"
> databases, it throws below error :
> {code}
> 0: jdbc:hive2://localhost:1/default> truncate table test.test;
> Error: Error while compiling statement: FAILED: SemanticException No valid
> privileges
> User user1 does not have privileges for TRUNCATETABLE
> The required privileges: Server=server1->Db=default->Table=test->action=*;
> (state=42000,code=4)
> {code}
> It works if user does "use database;" and then runs truncate table:
> {code}
> 0: jdbc:hive2://localhost:1/default> use test;
> INFO : Compiling
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41):
> use test
> INFO : Semantic Analysis Completed
> INFO : Returning Hive schema: Schema(fieldSchemas:null, properties:null)
> INFO : Completed compiling
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41);
> Time taken: 0.128 seconds
> INFO : Executing
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41):
> use test
> INFO : Starting task [Stage-0:DDL] in serial mode
> INFO : Completed executing
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41);
> Time taken: 0.014 seconds
> INFO : OK
> No rows affected (0.201 seconds)
> 0: jdbc:hive2://localhost:1/default> truncate table test.test;
> INFO : Compiling
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1):
> truncate table test.test
> INFO : Semantic Analysis Completed
> INFO : Returning Hive schema: Schema(fieldSchemas:null, properties:null)
> INFO : Completed compiling
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1);
> Time taken: 0.111 seconds
> INFO : Executing
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1):
> truncate table test.test
> INFO : Starting task [Stage-0:DDL] in serial mode
> INFO : Completed executing
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1);
> Time taken: 0.046 seconds
> INFO : OK
> No rows affected (0.179 seconds)
> 0: jdbc:hive2://localhost:1/default>
> {code}
> The workaround is to grant user permissions to the current data, then the
> issue will go away.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SENTRY-1546) Generic Policy provides bad error messages for Sentry exceptions
[
https://issues.apache.org/jira/browse/SENTRY-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
kalyan kumar kalvagadda updated SENTRY-1546:
Attachment: SENTRY-1546.001-sentry-ha-redesign.patch
> Generic Policy provides bad error messages for Sentry exceptions
>
>
> Key: SENTRY-1546
> URL: https://issues.apache.org/jira/browse/SENTRY-1546
> Project: Sentry
> Issue Type: Bug
>Affects Versions: 1.8.0, sentry-ha-redesign
>Reporter: Alexander Kolbasov
>Assignee: kalyan kumar kalvagadda
>Priority: Minor
> Labels: bite-sized
> Fix For: 1.8.0
>
> Attachments: SENTRY-1546.001.patch,
> SENTRY-1546.001-sentry-ha-redesign.patch, SENTRY-1546.002.patch,
> SENTRY-1546.003.patch, SENTRY-1546.005.patch
>
>
> I discovered that when you attempt to create a role that already exists the
> error message you get back from Thrift i just 'Role: foo' which is very
> confusing.
> The reason is that the SentryStore throws
> {code}SentryAlreadyExistsException("Role: " + trimmedRoleName);{code}
> and the generic policy processor passes the message as is:
> {code}
> public TCreateSentryRoleResponse create_sentry_role(
> final TCreateSentryRoleRequest request) throws TException {
> Response respose = requestHandle(new RequestHandler() {
> @Override
> public Response handle() throws Exception {
> validateClientVersion(request.getProtocol_version());
> authorize(request.getRequestorUserName(),
> getRequestorGroups(conf, request.getRequestorUserName()));
> store.createRole(request.getComponent(), request.getRoleName(),
> request.getRequestorUserName());
> return new Response(Status.OK());
> }
> });
> ...
> {code}
> The similar thing is happening for other requests and other Sentry-specific
> exceptions.
> The legacy policy processor does decorate the error a bit:
> {code}
> public TCreateSentryRoleResponse create_sentry_role(
> TCreateSentryRoleRequest request) throws TException {
> final Timer.Context timerContext = sentryMetrics.createRoleTimer.time();
> TCreateSentryRoleResponse response = new TCreateSentryRoleResponse();
> try {
> validateClientVersion(request.getProtocol_version());
> authorize(request.getRequestorUserName(),
> getRequestorGroups(request.getRequestorUserName()));
> sentryStore.createSentryRole(request.getRoleName());
> response.setStatus(Status.OK());
> notificationHandlerInvoker.create_sentry_role(request, response);
> } catch (SentryAlreadyExistsException e) {
> String msg = "Role: " + request + " already exists.";
> LOGGER.error(msg, e);
> response.setStatus(Status.AlreadyExists(msg, e));
> } catch (SentryAccessDeniedException e) {
> LOGGER.error(e.getMessage(), e);
> response.setStatus(Status.AccessDenied(e.getMessage(), e));
> } catch (SentryThriftAPIMismatchException e) {
> LOGGER.error(e.getMessage(), e);
> response.setStatus(Status.THRIFT_VERSION_MISMATCH(e.getMessage(), e));
> } catch (Exception e) {
> String msg = "Unknown error for request: " + request + ", message: " +
> e.getMessage();
> LOGGER.error(msg, e);
> response.setStatus(Status.RuntimeError(msg, e));
> } finally {
> ...
> {code}
> I think that it is better to just put the right message in the exception
> itself and do not decorate it later.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SENTRY-1546) Generic Policy provides bad error messages for Sentry exceptions
[
https://issues.apache.org/jira/browse/SENTRY-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Kolbasov updated SENTRY-1546:
---
Resolution: Fixed
Fix Version/s: 1.8.0
Status: Resolved (was: Patch Available)
[~kkalyan] Thank you for your contribution!
> Generic Policy provides bad error messages for Sentry exceptions
>
>
> Key: SENTRY-1546
> URL: https://issues.apache.org/jira/browse/SENTRY-1546
> Project: Sentry
> Issue Type: Bug
>Affects Versions: 1.8.0, sentry-ha-redesign
>Reporter: Alexander Kolbasov
>Assignee: kalyan kumar kalvagadda
>Priority: Minor
> Labels: bite-sized
> Fix For: 1.8.0
>
> Attachments: SENTRY-1546.001.patch, SENTRY-1546.002.patch,
> SENTRY-1546.003.patch, SENTRY-1546.005.patch
>
>
> I discovered that when you attempt to create a role that already exists the
> error message you get back from Thrift i just 'Role: foo' which is very
> confusing.
> The reason is that the SentryStore throws
> {code}SentryAlreadyExistsException("Role: " + trimmedRoleName);{code}
> and the generic policy processor passes the message as is:
> {code}
> public TCreateSentryRoleResponse create_sentry_role(
> final TCreateSentryRoleRequest request) throws TException {
> Response respose = requestHandle(new RequestHandler() {
> @Override
> public Response handle() throws Exception {
> validateClientVersion(request.getProtocol_version());
> authorize(request.getRequestorUserName(),
> getRequestorGroups(conf, request.getRequestorUserName()));
> store.createRole(request.getComponent(), request.getRoleName(),
> request.getRequestorUserName());
> return new Response(Status.OK());
> }
> });
> ...
> {code}
> The similar thing is happening for other requests and other Sentry-specific
> exceptions.
> The legacy policy processor does decorate the error a bit:
> {code}
> public TCreateSentryRoleResponse create_sentry_role(
> TCreateSentryRoleRequest request) throws TException {
> final Timer.Context timerContext = sentryMetrics.createRoleTimer.time();
> TCreateSentryRoleResponse response = new TCreateSentryRoleResponse();
> try {
> validateClientVersion(request.getProtocol_version());
> authorize(request.getRequestorUserName(),
> getRequestorGroups(request.getRequestorUserName()));
> sentryStore.createSentryRole(request.getRoleName());
> response.setStatus(Status.OK());
> notificationHandlerInvoker.create_sentry_role(request, response);
> } catch (SentryAlreadyExistsException e) {
> String msg = "Role: " + request + " already exists.";
> LOGGER.error(msg, e);
> response.setStatus(Status.AlreadyExists(msg, e));
> } catch (SentryAccessDeniedException e) {
> LOGGER.error(e.getMessage(), e);
> response.setStatus(Status.AccessDenied(e.getMessage(), e));
> } catch (SentryThriftAPIMismatchException e) {
> LOGGER.error(e.getMessage(), e);
> response.setStatus(Status.THRIFT_VERSION_MISMATCH(e.getMessage(), e));
> } catch (Exception e) {
> String msg = "Unknown error for request: " + request + ", message: " +
> e.getMessage();
> LOGGER.error(msg, e);
> response.setStatus(Status.RuntimeError(msg, e));
> } finally {
> ...
> {code}
> I think that it is better to just put the right message in the exception
> itself and do not decorate it later.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SENTRY-1546) Generic Policy provides bad error messages for Sentry exceptions
[
https://issues.apache.org/jira/browse/SENTRY-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15898150#comment-15898150
]
Hadoop QA commented on SENTRY-1546:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12856342/SENTRY-1546.005.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/2405/console
This message is automatically generated.
> Generic Policy provides bad error messages for Sentry exceptions
>
>
> Key: SENTRY-1546
> URL: https://issues.apache.org/jira/browse/SENTRY-1546
> Project: Sentry
> Issue Type: Bug
>Affects Versions: 1.8.0, sentry-ha-redesign
>Reporter: Alexander Kolbasov
>Assignee: kalyan kumar kalvagadda
>Priority: Minor
> Labels: bite-sized
> Attachments: SENTRY-1546.001.patch, SENTRY-1546.002.patch,
> SENTRY-1546.003.patch, SENTRY-1546.005.patch
>
>
> I discovered that when you attempt to create a role that already exists the
> error message you get back from Thrift i just 'Role: foo' which is very
> confusing.
> The reason is that the SentryStore throws
> {code}SentryAlreadyExistsException("Role: " + trimmedRoleName);{code}
> and the generic policy processor passes the message as is:
> {code}
> public TCreateSentryRoleResponse create_sentry_role(
> final TCreateSentryRoleRequest request) throws TException {
> Response respose = requestHandle(new RequestHandler() {
> @Override
> public Response handle() throws Exception {
> validateClientVersion(request.getProtocol_version());
> authorize(request.getRequestorUserName(),
> getRequestorGroups(conf, request.getRequestorUserName()));
> store.createRole(request.getComponent(), request.getRoleName(),
> request.getRequestorUserName());
> return new Response(Status.OK());
> }
> });
> ...
> {code}
> The similar thing is happening for other requests and other Sentry-specific
> exceptions.
> The legacy policy processor does decorate the error a bit:
> {code}
> public TCreateSentryRoleResponse create_sentry_role(
> TCreateSentryRoleRequest request) throws TException {
> final Timer.Context timerContext = sentryMetrics.createRoleTimer.time();
> TCreateSentryRoleResponse response = new TCreateSentryRoleResponse();
> try {
> validateClientVersion(request.getProtocol_version());
> authorize(request.getRequestorUserName(),
> getRequestorGroups(request.getRequestorUserName()));
> sentryStore.createSentryRole(request.getRoleName());
> response.setStatus(Status.OK());
> notificationHandlerInvoker.create_sentry_role(request, response);
> } catch (SentryAlreadyExistsException e) {
> String msg = "Role: " + request + " already exists.";
> LOGGER.error(msg, e);
> response.setStatus(Status.AlreadyExists(msg, e));
> } catch (SentryAccessDeniedException e) {
> LOGGER.error(e.getMessage(), e);
> response.setStatus(Status.AccessDenied(e.getMessage(), e));
> } catch (SentryThriftAPIMismatchException e) {
> LOGGER.error(e.getMessage(), e);
> response.setStatus(Status.THRIFT_VERSION_MISMATCH(e.getMessage(), e));
> } catch (Exception e) {
> String msg = "Unknown error for request: " + request + ", message: " +
> e.getMessage();
> LOGGER.error(msg, e);
> response.setStatus(Status.RuntimeError(msg, e));
> } finally {
> ...
> {code}
> I think that it is better to just put the right message in the exception
> itself and do not decorate it later.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SENTRY-1569) Upgrading SQL scripts for persist Perm/Path change
[ https://issues.apache.org/jira/browse/SENTRY-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kolbasov updated SENTRY-1569: --- Resolution: Fixed Status: Resolved (was: Patch Available) [~kkalyan] Thank you for your contribution! > Upgrading SQL scripts for persist Perm/Path change > -- > > Key: SENTRY-1569 > URL: https://issues.apache.org/jira/browse/SENTRY-1569 > Project: Sentry > Issue Type: Sub-task > Components: Hdfs Plugin >Reporter: Hao Hao >Assignee: kalyan kumar kalvagadda > Labels: hdfs-sync > Fix For: sentry-ha-redesign > > Attachments: SENTRY-1569.001-sentry-ha-redesign.patch, > SENTRY-1569.003-sentry-ha-redesign.patch > > > Upgrading SQL script for Sentry permission and HMS path change. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SENTRY-1548) Setting GrantOption to UNSET upsets Sentry
[
https://issues.apache.org/jira/browse/SENTRY-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
kalyan kumar kalvagadda updated SENTRY-1548:
Attachment: SENTRY-1548.001-sentry-ha-redesign.patch
> Setting GrantOption to UNSET upsets Sentry
> --
>
> Key: SENTRY-1548
> URL: https://issues.apache.org/jira/browse/SENTRY-1548
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 1.8.0, sentry-ha-redesign
>Reporter: Alexander Kolbasov
>Assignee: kalyan kumar kalvagadda
>Priority: Minor
> Labels: bite-sized
> Fix For: 1.8.0
>
> Attachments: SENTRY-1548.001.patch,
> SENTRY-1548.001-sentry-ha-redesign.patch, SENTRY-1548.002.patch,
> SENTRY-1548.003.patch, SENTRY-1548.005.patch, SENTRY-1548.006.patch,
> SENTRY-1548.007.patch, SENTRY-1548.008.patch, SENTRY-1548.009.patch
>
>
> If we send a Thrift request to sentry (using regular api) with GrantOption
> set to UNSET (-1) we get the following error:
> {code}
> TransactionManager.executeTransactionWithRetry(TransactionManager.java:102)]
> The transaction has reac
> hed max retry number, will not retry again.
> javax.jdo.JDODataStoreException: Insert of object
> "org.apache.sentry.provider.db.service.model.MSentryPrivilege@6bbfd4c9" using
> statement "INSERT INTO `SENTRY_DB_PRIVILEGE`
> (`DB_PRIVILEGE_ID`,`SERVER_NAME`,`WITH_GRANT_OPTION`,`CREATE_TIME`,`TABLE_NAME`,`URI`,`ACTION`,`COLUMN_NAME`,`DB_NAME`,`PRIVILEGE_SCOPE`)
> VALUES (?,?,?,?,?,?,?,?,?,?)" failed : Column 'WITH_GRANT_OPTION' cannot be
> null
> at
> org.datanucleus.api.jdo.NucleusJDOHelper.getJDOExceptionForNucleusException(NucleusJDOHelper.java:451)
> at
> org.datanucleus.api.jdo.JDOPersistenceManager.jdoMakePersistent(JDOPersistenceManager.java:732)
> at
> org.datanucleus.api.jdo.JDOPersistenceManager.makePersistent(JDOPersistenceManager.java:752)
> at
> org.apache.sentry.provider.db.service.persistent.SentryStore.alterSentryRoleGrantPrivilegeCore(SentryStore.java:438)
> at
> org.apache.sentry.provider.db.service.persistent.SentryStore.access$500(SentryStore.java:95)
> at
> org.apache.sentry.provider.db.service.persistent.SentryStore$8.execute(SentryStore.java:374)
> at
> org.apache.sentry.provider.db.service.persistent.TransactionManager.executeTransaction(TransactionManager.java:72)
> at
> org.apache.sentry.provider.db.service.persistent.TransactionManager.executeTransactionWithRetry(TransactionManager.java:93)
> at
> org.apache.sentry.provider.db.service.persistent.SentryStore.alterSentryRoleGrantPrivileges(SentryStore.java:367)
> at
> org.apache.sentry.provider.db.service.thrift.SentryPolicyStoreProcessor.alter_sentry_role_grant_privilege(SentryPolicyStoreProcessor.java:280)
> at
> org.apache.sentry.provider.db.service.thrift.SentryPolicyService$Processor$alter_sentry_role_grant_privilege.getResult(SentryPolicyService.java:1237)
> at
> org.apache.sentry.provider.db.service.thrift.SentryPolicyService$Processor$alter_sentry_role_grant_privilege.getResult(SentryPolicyService.java:1222)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.sentry.provider.db.service.thrift.SentryProcessorWrapper.process(SentryProcessorWrapper.java:35)
> at
> org.apache.thrift.TMultiplexedProcessor.process(TMultiplexedProcessor.java:123)
> at
> org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:286)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> NestedThrowablesStackTrace:
> com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException:
> Column 'WITH_GRANT_OPTION' cannot be null
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at com.mysql.jdbc.Util.handleNewInstance(Util.java:404)
> at com.mysql.jdbc.Util.getInstance(Util.java:387)
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:934)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3966)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3902)
> at
[jira] [Commented] (SENTRY-1548) Setting GrantOption to UNSET upsets Sentry
[
https://issues.apache.org/jira/browse/SENTRY-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897958#comment-15897958
]
Alexander Kolbasov commented on SENTRY-1548:
[~kkalyan] Thank you for your contribution!
> Setting GrantOption to UNSET upsets Sentry
> --
>
> Key: SENTRY-1548
> URL: https://issues.apache.org/jira/browse/SENTRY-1548
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 1.8.0, sentry-ha-redesign
>Reporter: Alexander Kolbasov
>Assignee: kalyan kumar kalvagadda
>Priority: Minor
> Labels: bite-sized
> Fix For: 1.8.0
>
> Attachments: SENTRY-1548.001.patch, SENTRY-1548.002.patch,
> SENTRY-1548.003.patch, SENTRY-1548.005.patch, SENTRY-1548.006.patch,
> SENTRY-1548.007.patch, SENTRY-1548.008.patch, SENTRY-1548.009.patch
>
>
> If we send a Thrift request to sentry (using regular api) with GrantOption
> set to UNSET (-1) we get the following error:
> {code}
> TransactionManager.executeTransactionWithRetry(TransactionManager.java:102)]
> The transaction has reac
> hed max retry number, will not retry again.
> javax.jdo.JDODataStoreException: Insert of object
> "org.apache.sentry.provider.db.service.model.MSentryPrivilege@6bbfd4c9" using
> statement "INSERT INTO `SENTRY_DB_PRIVILEGE`
> (`DB_PRIVILEGE_ID`,`SERVER_NAME`,`WITH_GRANT_OPTION`,`CREATE_TIME`,`TABLE_NAME`,`URI`,`ACTION`,`COLUMN_NAME`,`DB_NAME`,`PRIVILEGE_SCOPE`)
> VALUES (?,?,?,?,?,?,?,?,?,?)" failed : Column 'WITH_GRANT_OPTION' cannot be
> null
> at
> org.datanucleus.api.jdo.NucleusJDOHelper.getJDOExceptionForNucleusException(NucleusJDOHelper.java:451)
> at
> org.datanucleus.api.jdo.JDOPersistenceManager.jdoMakePersistent(JDOPersistenceManager.java:732)
> at
> org.datanucleus.api.jdo.JDOPersistenceManager.makePersistent(JDOPersistenceManager.java:752)
> at
> org.apache.sentry.provider.db.service.persistent.SentryStore.alterSentryRoleGrantPrivilegeCore(SentryStore.java:438)
> at
> org.apache.sentry.provider.db.service.persistent.SentryStore.access$500(SentryStore.java:95)
> at
> org.apache.sentry.provider.db.service.persistent.SentryStore$8.execute(SentryStore.java:374)
> at
> org.apache.sentry.provider.db.service.persistent.TransactionManager.executeTransaction(TransactionManager.java:72)
> at
> org.apache.sentry.provider.db.service.persistent.TransactionManager.executeTransactionWithRetry(TransactionManager.java:93)
> at
> org.apache.sentry.provider.db.service.persistent.SentryStore.alterSentryRoleGrantPrivileges(SentryStore.java:367)
> at
> org.apache.sentry.provider.db.service.thrift.SentryPolicyStoreProcessor.alter_sentry_role_grant_privilege(SentryPolicyStoreProcessor.java:280)
> at
> org.apache.sentry.provider.db.service.thrift.SentryPolicyService$Processor$alter_sentry_role_grant_privilege.getResult(SentryPolicyService.java:1237)
> at
> org.apache.sentry.provider.db.service.thrift.SentryPolicyService$Processor$alter_sentry_role_grant_privilege.getResult(SentryPolicyService.java:1222)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.sentry.provider.db.service.thrift.SentryProcessorWrapper.process(SentryProcessorWrapper.java:35)
> at
> org.apache.thrift.TMultiplexedProcessor.process(TMultiplexedProcessor.java:123)
> at
> org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:286)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> NestedThrowablesStackTrace:
> com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException:
> Column 'WITH_GRANT_OPTION' cannot be null
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at com.mysql.jdbc.Util.handleNewInstance(Util.java:404)
> at com.mysql.jdbc.Util.getInstance(Util.java:387)
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:934)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3966)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3902)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2526)
>
[jira] [Updated] (SENTRY-1548) Setting GrantOption to UNSET upsets Sentry
[
https://issues.apache.org/jira/browse/SENTRY-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
kalyan kumar kalvagadda updated SENTRY-1548:
Affects Version/s: sentry-ha-redesign
1.8.0
> Setting GrantOption to UNSET upsets Sentry
> --
>
> Key: SENTRY-1548
> URL: https://issues.apache.org/jira/browse/SENTRY-1548
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 1.8.0, sentry-ha-redesign
>Reporter: Alexander Kolbasov
>Assignee: kalyan kumar kalvagadda
>Priority: Minor
> Labels: bite-sized
> Attachments: SENTRY-1548.001.patch, SENTRY-1548.002.patch,
> SENTRY-1548.003.patch, SENTRY-1548.005.patch, SENTRY-1548.006.patch,
> SENTRY-1548.007.patch, SENTRY-1548.008.patch, SENTRY-1548.009.patch
>
>
> If we send a Thrift request to sentry (using regular api) with GrantOption
> set to UNSET (-1) we get the following error:
> {code}
> TransactionManager.executeTransactionWithRetry(TransactionManager.java:102)]
> The transaction has reac
> hed max retry number, will not retry again.
> javax.jdo.JDODataStoreException: Insert of object
> "org.apache.sentry.provider.db.service.model.MSentryPrivilege@6bbfd4c9" using
> statement "INSERT INTO `SENTRY_DB_PRIVILEGE`
> (`DB_PRIVILEGE_ID`,`SERVER_NAME`,`WITH_GRANT_OPTION`,`CREATE_TIME`,`TABLE_NAME`,`URI`,`ACTION`,`COLUMN_NAME`,`DB_NAME`,`PRIVILEGE_SCOPE`)
> VALUES (?,?,?,?,?,?,?,?,?,?)" failed : Column 'WITH_GRANT_OPTION' cannot be
> null
> at
> org.datanucleus.api.jdo.NucleusJDOHelper.getJDOExceptionForNucleusException(NucleusJDOHelper.java:451)
> at
> org.datanucleus.api.jdo.JDOPersistenceManager.jdoMakePersistent(JDOPersistenceManager.java:732)
> at
> org.datanucleus.api.jdo.JDOPersistenceManager.makePersistent(JDOPersistenceManager.java:752)
> at
> org.apache.sentry.provider.db.service.persistent.SentryStore.alterSentryRoleGrantPrivilegeCore(SentryStore.java:438)
> at
> org.apache.sentry.provider.db.service.persistent.SentryStore.access$500(SentryStore.java:95)
> at
> org.apache.sentry.provider.db.service.persistent.SentryStore$8.execute(SentryStore.java:374)
> at
> org.apache.sentry.provider.db.service.persistent.TransactionManager.executeTransaction(TransactionManager.java:72)
> at
> org.apache.sentry.provider.db.service.persistent.TransactionManager.executeTransactionWithRetry(TransactionManager.java:93)
> at
> org.apache.sentry.provider.db.service.persistent.SentryStore.alterSentryRoleGrantPrivileges(SentryStore.java:367)
> at
> org.apache.sentry.provider.db.service.thrift.SentryPolicyStoreProcessor.alter_sentry_role_grant_privilege(SentryPolicyStoreProcessor.java:280)
> at
> org.apache.sentry.provider.db.service.thrift.SentryPolicyService$Processor$alter_sentry_role_grant_privilege.getResult(SentryPolicyService.java:1237)
> at
> org.apache.sentry.provider.db.service.thrift.SentryPolicyService$Processor$alter_sentry_role_grant_privilege.getResult(SentryPolicyService.java:1222)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.sentry.provider.db.service.thrift.SentryProcessorWrapper.process(SentryProcessorWrapper.java:35)
> at
> org.apache.thrift.TMultiplexedProcessor.process(TMultiplexedProcessor.java:123)
> at
> org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:286)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> NestedThrowablesStackTrace:
> com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException:
> Column 'WITH_GRANT_OPTION' cannot be null
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at com.mysql.jdbc.Util.handleNewInstance(Util.java:404)
> at com.mysql.jdbc.Util.getInstance(Util.java:387)
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:934)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3966)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3902)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2526)
> at
[jira] [Updated] (SENTRY-1546) Generic Policy provides bad error messages for Sentry exceptions
[
https://issues.apache.org/jira/browse/SENTRY-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Kolbasov updated SENTRY-1546:
---
Affects Version/s: sentry-ha-redesign
> Generic Policy provides bad error messages for Sentry exceptions
>
>
> Key: SENTRY-1546
> URL: https://issues.apache.org/jira/browse/SENTRY-1546
> Project: Sentry
> Issue Type: Bug
>Affects Versions: 1.8.0, sentry-ha-redesign
>Reporter: Alexander Kolbasov
>Assignee: kalyan kumar kalvagadda
>Priority: Minor
> Labels: bite-sized
> Attachments: SENTRY-1546.001.patch, SENTRY-1546.002.patch,
> SENTRY-1546.003.patch
>
>
> I discovered that when you attempt to create a role that already exists the
> error message you get back from Thrift i just 'Role: foo' which is very
> confusing.
> The reason is that the SentryStore throws
> {code}SentryAlreadyExistsException("Role: " + trimmedRoleName);{code}
> and the generic policy processor passes the message as is:
> {code}
> public TCreateSentryRoleResponse create_sentry_role(
> final TCreateSentryRoleRequest request) throws TException {
> Response respose = requestHandle(new RequestHandler() {
> @Override
> public Response handle() throws Exception {
> validateClientVersion(request.getProtocol_version());
> authorize(request.getRequestorUserName(),
> getRequestorGroups(conf, request.getRequestorUserName()));
> store.createRole(request.getComponent(), request.getRoleName(),
> request.getRequestorUserName());
> return new Response(Status.OK());
> }
> });
> ...
> {code}
> The similar thing is happening for other requests and other Sentry-specific
> exceptions.
> The legacy policy processor does decorate the error a bit:
> {code}
> public TCreateSentryRoleResponse create_sentry_role(
> TCreateSentryRoleRequest request) throws TException {
> final Timer.Context timerContext = sentryMetrics.createRoleTimer.time();
> TCreateSentryRoleResponse response = new TCreateSentryRoleResponse();
> try {
> validateClientVersion(request.getProtocol_version());
> authorize(request.getRequestorUserName(),
> getRequestorGroups(request.getRequestorUserName()));
> sentryStore.createSentryRole(request.getRoleName());
> response.setStatus(Status.OK());
> notificationHandlerInvoker.create_sentry_role(request, response);
> } catch (SentryAlreadyExistsException e) {
> String msg = "Role: " + request + " already exists.";
> LOGGER.error(msg, e);
> response.setStatus(Status.AlreadyExists(msg, e));
> } catch (SentryAccessDeniedException e) {
> LOGGER.error(e.getMessage(), e);
> response.setStatus(Status.AccessDenied(e.getMessage(), e));
> } catch (SentryThriftAPIMismatchException e) {
> LOGGER.error(e.getMessage(), e);
> response.setStatus(Status.THRIFT_VERSION_MISMATCH(e.getMessage(), e));
> } catch (Exception e) {
> String msg = "Unknown error for request: " + request + ", message: " +
> e.getMessage();
> LOGGER.error(msg, e);
> response.setStatus(Status.RuntimeError(msg, e));
> } finally {
> ...
> {code}
> I think that it is better to just put the right message in the exception
> itself and do not decorate it later.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (SENTRY-1638) Update SQL script of MSentryPathChange table to add a column for notification ID
[ https://issues.apache.org/jira/browse/SENTRY-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kalyan kumar kalvagadda reopened SENTRY-1638: - > Update SQL script of MSentryPathChange table to add a column for notification > ID > > > Key: SENTRY-1638 > URL: https://issues.apache.org/jira/browse/SENTRY-1638 > Project: Sentry > Issue Type: Sub-task > Components: Hdfs Plugin >Affects Versions: sentry-ha-redesign >Reporter: Hao Hao >Assignee: kalyan kumar kalvagadda > Fix For: sentry-ha-redesign > > Attachments: SENTRY-1638.01-sentry-ha-redesign.patch, > SENTRY-1638.02-sentry-ha-redesign.patch > > > For follow up of SENTRY-1448, the SQL Script of MSentryPathChange table needs > to be updated to add a column for notification ID to support the change in > SENTRY-1448. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SENTRY-1642) Integrate Sentry build with Error Prone
[ https://issues.apache.org/jira/browse/SENTRY-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kolbasov updated SENTRY-1642: --- Fix Version/s: sentry-ha-redesign > Integrate Sentry build with Error Prone > --- > > Key: SENTRY-1642 > URL: https://issues.apache.org/jira/browse/SENTRY-1642 > Project: Sentry > Issue Type: Improvement > Components: Sentry >Affects Versions: 1.8.0, sentry-ha-redesign >Reporter: Alexander Kolbasov >Assignee: Alexander Kolbasov > Fix For: 1.8.0, sentry-ha-redesign > > Attachments: SENTRY-1642.002.patch > > > Error Prone (http://errorprone.info/) is a nice tool to catch various Java > bugs. We should integrate it with Sentry build and fix all issues discovered. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SENTRY-1645) Port SENTRY-1642 to sentry-ha-redesign
[ https://issues.apache.org/jira/browse/SENTRY-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kolbasov updated SENTRY-1645: --- Resolution: Fixed Status: Resolved (was: Patch Available) > Port SENTRY-1642 to sentry-ha-redesign > -- > > Key: SENTRY-1645 > URL: https://issues.apache.org/jira/browse/SENTRY-1645 > Project: Sentry > Issue Type: Sub-task > Components: Sentry >Affects Versions: sentry-ha-redesign >Reporter: Alexander Kolbasov >Assignee: Alexander Kolbasov > Fix For: sentry-ha-redesign > > Attachments: SENTRY-1645.001-sentry-ha-redesign.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SENTRY-1646) Unable to truncate table .; from "default" databases
[
https://issues.apache.org/jira/browse/SENTRY-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897761#comment-15897761
]
Yongzhi Chen commented on SENTRY-1646:
--
[~haohao], could you help me submit the patch for the pre-commit build and
review it ? Thanks
> Unable to truncate table .; from "default" databases
> -
>
> Key: SENTRY-1646
> URL: https://issues.apache.org/jira/browse/SENTRY-1646
> Project: Sentry
> Issue Type: Bug
> Components: Hive Plugin
>Affects Versions: 1.7.0
>Reporter: Eric Lin
>Priority: Critical
> Attachments: SENTRY-1646.1.patch
>
>
> When the user is doing truncate table .; from "default"
> databases, it throws below error :
> {code}
> 0: jdbc:hive2://localhost:1/default> truncate table test.test;
> Error: Error while compiling statement: FAILED: SemanticException No valid
> privileges
> User user1 does not have privileges for TRUNCATETABLE
> The required privileges: Server=server1->Db=default->Table=test->action=*;
> (state=42000,code=4)
> {code}
> It works if user does "use database;" and then runs truncate table:
> {code}
> 0: jdbc:hive2://localhost:1/default> use test;
> INFO : Compiling
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41):
> use test
> INFO : Semantic Analysis Completed
> INFO : Returning Hive schema: Schema(fieldSchemas:null, properties:null)
> INFO : Completed compiling
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41);
> Time taken: 0.128 seconds
> INFO : Executing
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41):
> use test
> INFO : Starting task [Stage-0:DDL] in serial mode
> INFO : Completed executing
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41);
> Time taken: 0.014 seconds
> INFO : OK
> No rows affected (0.201 seconds)
> 0: jdbc:hive2://localhost:1/default> truncate table test.test;
> INFO : Compiling
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1):
> truncate table test.test
> INFO : Semantic Analysis Completed
> INFO : Returning Hive schema: Schema(fieldSchemas:null, properties:null)
> INFO : Completed compiling
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1);
> Time taken: 0.111 seconds
> INFO : Executing
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1):
> truncate table test.test
> INFO : Starting task [Stage-0:DDL] in serial mode
> INFO : Completed executing
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1);
> Time taken: 0.046 seconds
> INFO : OK
> No rows affected (0.179 seconds)
> 0: jdbc:hive2://localhost:1/default>
> {code}
> The workaround is to grant user permissions to the current data, then the
> issue will go away.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SENTRY-1646) Unable to truncate table .; from "default" databases
[
https://issues.apache.org/jira/browse/SENTRY-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yongzhi Chen updated SENTRY-1646:
-
Attachment: SENTRY-1646.1.patch
The issue can be reproduced by the changed test of the attached patch. Fix the
issue by getting the currOutDB inform from qualified table name if exists.
> Unable to truncate table .; from "default" databases
> -
>
> Key: SENTRY-1646
> URL: https://issues.apache.org/jira/browse/SENTRY-1646
> Project: Sentry
> Issue Type: Bug
> Components: Hive Plugin
>Affects Versions: 1.7.0
>Reporter: Eric Lin
>Priority: Critical
> Attachments: SENTRY-1646.1.patch
>
>
> When the user is doing truncate table .; from "default"
> databases, it throws below error :
> {code}
> 0: jdbc:hive2://localhost:1/default> truncate table test.test;
> Error: Error while compiling statement: FAILED: SemanticException No valid
> privileges
> User user1 does not have privileges for TRUNCATETABLE
> The required privileges: Server=server1->Db=default->Table=test->action=*;
> (state=42000,code=4)
> {code}
> It works if user does "use database;" and then runs truncate table:
> {code}
> 0: jdbc:hive2://localhost:1/default> use test;
> INFO : Compiling
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41):
> use test
> INFO : Semantic Analysis Completed
> INFO : Returning Hive schema: Schema(fieldSchemas:null, properties:null)
> INFO : Completed compiling
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41);
> Time taken: 0.128 seconds
> INFO : Executing
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41):
> use test
> INFO : Starting task [Stage-0:DDL] in serial mode
> INFO : Completed executing
> command(queryId=hive_2017022814_654cb0ff-6925-42a4-ba67-a151cd2e4f41);
> Time taken: 0.014 seconds
> INFO : OK
> No rows affected (0.201 seconds)
> 0: jdbc:hive2://localhost:1/default> truncate table test.test;
> INFO : Compiling
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1):
> truncate table test.test
> INFO : Semantic Analysis Completed
> INFO : Returning Hive schema: Schema(fieldSchemas:null, properties:null)
> INFO : Completed compiling
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1);
> Time taken: 0.111 seconds
> INFO : Executing
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1):
> truncate table test.test
> INFO : Starting task [Stage-0:DDL] in serial mode
> INFO : Completed executing
> command(queryId=hive_2017022814_2441690e-7523-4525-aeb2-5105e31f51c1);
> Time taken: 0.046 seconds
> INFO : OK
> No rows affected (0.179 seconds)
> 0: jdbc:hive2://localhost:1/default>
> {code}
> The workaround is to grant user permissions to the current data, then the
> issue will go away.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
