[jira] [Commented] (KUDU-3178) An option to terminate connections which have been open for very long time

2020-07-30 Thread Alexey Serbin (Jira)


[ 
https://issues.apache.org/jira/browse/KUDU-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17168126#comment-17168126
 ] 

Alexey Serbin commented on KUDU-3178:
-

Ah, probably the essence was in _not_ terminating a connection, but instead 
send back authn error that would lead to re-authentication (e.g. re-acquiring 
authn token).  Yes, that might be a good option in addressing the actual issue 
behind those long-living connections.  Thanks!

> An option to terminate connections which have been open for very long time
> --
>
> Key: KUDU-3178
> URL: https://issues.apache.org/jira/browse/KUDU-3178
> Project: Kudu
>  Issue Type: Improvement
>  Components: master, security, tserver
>Reporter: Alexey Serbin
>Priority: Major
>
> A Kudu client can open a connection to {{kudu-master}} or {{kudu-tserver}} 
> and keep that connection open indefinitely by issuing some method at least 
> once every {{\-\-rpc_default_keepalive_time_ms}} interval (e.g., call 
> {{Ping()}} method).  This means there isn't a limit on how long an client can 
> have access to cluster once it's authenticated, unless {{kudu-master}} and 
> {{kudu-tserver}} processes are restarted.  When fine-grained authorization if 
> enforced, this issue is really benign because such lingering clients are 
> unable to call any methods that require authz token to be provided.
> It would be nice to address this by providing an option to terminate 
> connections which were established long time ago.  Both the interval of the 
> maximum connection lifetime and whether to terminate over-the-TTL connections 
> should be controlled by flags.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (KUDU-3178) An option to terminate connections which have been open for very long time

2020-07-30 Thread Alexey Serbin (Jira)


[ 
https://issues.apache.org/jira/browse/KUDU-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17168123#comment-17168123
 ] 

Alexey Serbin commented on KUDU-3178:
-

Why 'instead'?  That's exactly one of the way I was thinking to implement this 
:)

> An option to terminate connections which have been open for very long time
> --
>
> Key: KUDU-3178
> URL: https://issues.apache.org/jira/browse/KUDU-3178
> Project: Kudu
>  Issue Type: Improvement
>  Components: master, security, tserver
>Reporter: Alexey Serbin
>Priority: Major
>
> A Kudu client can open a connection to {{kudu-master}} or {{kudu-tserver}} 
> and keep that connection open indefinitely by issuing some method at least 
> once every {{\-\-rpc_default_keepalive_time_ms}} interval (e.g., call 
> {{Ping()}} method).  This means there isn't a limit on how long an client can 
> have access to cluster once it's authenticated, unless {{kudu-master}} and 
> {{kudu-tserver}} processes are restarted.  When fine-grained authorization if 
> enforced, this issue is really benign because such lingering clients are 
> unable to call any methods that require authz token to be provided.
> It would be nice to address this by providing an option to terminate 
> connections which were established long time ago.  Both the interval of the 
> maximum connection lifetime and whether to terminate over-the-TTL connections 
> should be controlled by flags.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (KUDU-3178) An option to terminate connections which have been open for very long time

2020-07-30 Thread Todd Lipcon (Jira)


[ 
https://issues.apache.org/jira/browse/KUDU-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17168086#comment-17168086
 ] 

Todd Lipcon commented on KUDU-3178:
---

Could we instead just keep track of the expiration time of the authn token when 
the connection is established, and before processing any RPC call, verify that 
the time has not passed? If it has passed we can send back an authentication 
error that looks just the same as if authentication failed during the initial 
handshake, which should trigger the client's existing "fetch new token" paths, 
right?

> An option to terminate connections which have been open for very long time
> --
>
> Key: KUDU-3178
> URL: https://issues.apache.org/jira/browse/KUDU-3178
> Project: Kudu
>  Issue Type: Improvement
>  Components: master, security, tserver
>Reporter: Alexey Serbin
>Priority: Major
>
> A Kudu client can open a connection to {{kudu-master}} or {{kudu-tserver}} 
> and keep that connection open indefinitely by issuing some method at least 
> once every {{\-\-rpc_default_keepalive_time_ms}} interval (e.g., call 
> {{Ping()}} method).  This means there isn't a limit on how long an client can 
> have access to cluster once it's authenticated, unless {{kudu-master}} and 
> {{kudu-tserver}} processes are restarted.  When fine-grained authorization if 
> enforced, this issue is really benign because such lingering clients are 
> unable to call any methods that require authz token to be provided.
> It would be nice to address this by providing an option to terminate 
> connections which were established long time ago.  Both the interval of the 
> maximum connection lifetime and whether to terminate over-the-TTL connections 
> should be controlled by flags.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)