[jira] [Resolved] (KNOX-687) Address new Coverity Scan issues
[ https://issues.apache.org/jira/browse/KNOX-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Minder resolved KNOX-687. --- Resolution: Fixed Resolved via the following commit. Not sure why this wasn't noted automatically. 7edeac5d80e161663fea14bafd4d7f662d25d767 | 2016-03-14 15:47:26 -0400 | Kevin Minder | [KNOX-687] - Address new Coverity Scan issues > Address new Coverity Scan issues > > > Key: KNOX-687 > URL: https://issues.apache.org/jira/browse/KNOX-687 > Project: Apache Knox > Issue Type: Task > Components: Server >Affects Versions: 0.9.0 >Reporter: Kevin Minder >Assignee: Kevin Minder >Priority: Critical > Fix For: 0.9.0 > > > Please find the latest report on new defect(s) introduced to Apache Knox > found with Coverity Scan. > 6 new defect(s) introduced to Apache Knox found with Coverity Scan. > 2 defect(s), reported by Coverity Scan earlier, were marked fixed in the > recent build analyzed by Coverity Scan. > New defect(s) Reported-by: Coverity Scan > Showing 6 of 6 defect(s) > {code} > ** CID 1352655: Resource leaks (RESOURCE_LEAK) > /gateway-server/src/main/java/org/apache/hadoop/gateway/services/security/impl/JettySSLService.java: > 245 in > org.apache.hadoop.gateway.services.security.impl.JettySSLService.loadKeyStore(java.lang.String, > java.lang.String, char[])() > > *** CID 1352655: Resource leaks (RESOURCE_LEAK) > /gateway-server/src/main/java/org/apache/hadoop/gateway/services/security/impl/JettySSLService.java: > 245 in > org.apache.hadoop.gateway.services.security.impl.JettySSLService.loadKeyStore(java.lang.String, > java.lang.String, char[])() > 239 } > 240 > 241 private static KeyStore loadKeyStore( String fileName, String > storeType, char[] storePass ) throws CertificateException, > NoSuchAlgorithmException, IOException, KeyStoreException { > 242 KeyStore keystore = KeyStore.getInstance(storeType); > 243 InputStream is = new FileInputStream(fileName); > 244 keystore.load( is, storePass ); > >>> CID 1352655: Resource leaks (RESOURCE_LEAK) > >>> Variable "is" going out of scope leaks the resource it refers to. > 245 return keystore; > 246 } > 247 > ** CID 1352654: Null pointer dereferences (NULL_RETURNS) > /gateway-server/src/main/java/org/apache/hadoop/gateway/GatewayServer.java: > 291 in > org.apache.hadoop.gateway.GatewayServer.startGateway(org.apache.hadoop.gateway.config.GatewayConfig, > org.apache.hadoop.gateway.services.GatewayServices)() > > *** CID 1352654: Null pointer dereferences (NULL_RETURNS) > /gateway-server/src/main/java/org/apache/hadoop/gateway/GatewayServer.java: > 291 in > org.apache.hadoop.gateway.GatewayServer.startGateway(org.apache.hadoop.gateway.config.GatewayConfig, > org.apache.hadoop.gateway.services.GatewayServices)() > 285 services = svcs; > 286 //} > 287 //KM] > 288 services.start(); > 289 DeploymentFactory.setGatewayServices(services); > 290 server.start(); > >>> CID 1352654: Null pointer dereferences (NULL_RETURNS) > >>> Calling a method on null object > >>> "org.apache.hadoop.gateway.GatewayServer.server.jetty.getURI()". > 291 log.startedGateway( server.jetty.getURI().getPort() ); > 292 return server; > 293 } > 294 } > 295 > 296 public GatewayServer( GatewayConfig config ) { > ** CID 1352651: Medium impact security (HARDCODED_CREDENTIALS) > /gateway-server/src/main/java/org/apache/hadoop/gateway/services/security/impl/JettySSLService.java: > 244 in > org.apache.hadoop.gateway.services.security.impl.JettySSLService.loadKeyStore(java.lang.String, > java.lang.String, char[])() > > *** CID 1352651: Medium impact security (HARDCODED_CREDENTIALS) > /gateway-server/src/main/java/org/apache/hadoop/gateway/services/security/impl/JettySSLService.java: > 244 in > org.apache.hadoop.gateway.services.security.impl.JettySSLService.loadKeyStore(java.lang.String, > java.lang.String, char[])() > 238 > 239 } > 240 > 241 private static KeyStore loadKeyStore( String fileName, String > storeType, char[] storePass ) throws CertificateException, > NoSuchAlgorithmException, IOException, KeyStoreException { > 242 KeyStore keystore = KeyStore.getInstance(storeType); > 243 InputStream is = new FileInputStream(fileName); > >>> CID 1352651: Medium impact security (HARDCODED_CREDENTIALS) > >>> "java.security.KeySt
[jira] [Resolved] (KNOX-670) Knox should be able to host simple web apps
[ https://issues.apache.org/jira/browse/KNOX-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Minder resolved KNOX-670. --- Resolution: Fixed Closing now that separate jiras are filed for additional semi-related work. > Knox should be able to host simple web apps > --- > > Key: KNOX-670 > URL: https://issues.apache.org/jira/browse/KNOX-670 > Project: Apache Knox > Issue Type: Bug > Components: Server >Reporter: Larry McCay >Assignee: Kevin Minder > Fix For: 0.9.0 > > Attachments: KNOX-670_001.patch, KNOX-670_002.patch, > KNOX-670_003.patch > > > I think that we need the ability to serve up arbitrary web app resources. > Given a conf/applications along side conf/topologies, we should be able to > spin up a simple application that can be used as a central login facility > with KnoxSSO, a management UI or any number of simple applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KNOX-699) External meta-data for simple hosted web apps
[ https://issues.apache.org/jira/browse/KNOX-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15216765#comment-15216765 ] ASF subversion and git services commented on KNOX-699: -- Commit 6c7a0599ccb7cae2be77bd46ebc4d41eccd1a4c8 in knox's branch refs/heads/master from [~kevin.minder] [ https://git-wip-us.apache.org/repos/asf?p=knox.git;h=6c7a059 ] KNOX-699] - External meta-data for simple hosted web apps > External meta-data for simple hosted web apps > - > > Key: KNOX-699 > URL: https://issues.apache.org/jira/browse/KNOX-699 > Project: Apache Knox > Issue Type: Bug > Components: Server >Affects Versions: 0.9.0 >Reporter: Kevin Minder > Fix For: 0.9.0 > > Attachments: KNOX-699_001.patch > > > Currently the meta-data for hosted web apps must be stored in the root of > those web apps. Since the idea is largely to be able to host "stock" web > apps unmodified this is not ideal. It should be possible to store the Knox > specific app meta-data outside of the application "archive" and apply that > meta-data at deployment time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (KNOX-699) External meta-data for simple hosted web apps
[ https://issues.apache.org/jira/browse/KNOX-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Minder reassigned KNOX-699: - Assignee: Kevin Minder > External meta-data for simple hosted web apps > - > > Key: KNOX-699 > URL: https://issues.apache.org/jira/browse/KNOX-699 > Project: Apache Knox > Issue Type: Bug > Components: Server >Affects Versions: 0.9.0 >Reporter: Kevin Minder >Assignee: Kevin Minder > Fix For: 0.9.0 > > Attachments: KNOX-699_001.patch > > > Currently the meta-data for hosted web apps must be stored in the root of > those web apps. Since the idea is largely to be able to host "stock" web > apps unmodified this is not ideal. It should be possible to store the Knox > specific app meta-data outside of the application "archive" and apply that > meta-data at deployment time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (KNOX-699) External meta-data for simple hosted web apps
[ https://issues.apache.org/jira/browse/KNOX-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Minder resolved KNOX-699. --- Resolution: Fixed > External meta-data for simple hosted web apps > - > > Key: KNOX-699 > URL: https://issues.apache.org/jira/browse/KNOX-699 > Project: Apache Knox > Issue Type: Bug > Components: Server >Affects Versions: 0.9.0 >Reporter: Kevin Minder >Assignee: Kevin Minder > Fix For: 0.9.0 > > Attachments: KNOX-699_001.patch > > > Currently the meta-data for hosted web apps must be stored in the root of > those web apps. Since the idea is largely to be able to host "stock" web > apps unmodified this is not ideal. It should be possible to store the Knox > specific app meta-data outside of the application "archive" and apply that > meta-data at deployment time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KNOX-618) Rewrite function for accessing header values
[ https://issues.apache.org/jira/browse/KNOX-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Minder updated KNOX-618: -- Attachment: KNOX-618_001.patch > Rewrite function for accessing header values > > > Key: KNOX-618 > URL: https://issues.apache.org/jira/browse/KNOX-618 > Project: Apache Knox > Issue Type: New Feature > Components: Server >Affects Versions: 0.6.0 >Reporter: Kevin Minder >Assignee: Kevin Minder >Priority: Minor > Fix For: Future > > Attachments: KNOX-618_001.patch > > > I recently ran into a situation where it would have been useful to have > access to header values in the rewrite rules. In particular it would be > useful sometimes to API version with a header like this. > {code} > > template=""{scheme}://{host}:{port}/api/{$header[version]}/{path}?{**}""/> > > {code} > As implied above the rewrite function plugin model seems like an excellent > way to provide basic access to header information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KNOX-537) Linux PAM Authentication Provider
[ https://issues.apache.org/jira/browse/KNOX-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15216939#comment-15216939 ] Larry McCay commented on KNOX-537: -- [~jeffreyr97] - We are going to be closing down on the 0.9.0 release at the end of the week and cutting a release candidate. It is unfortunate that this contribution will not make it in again. If there are others that are waiting for this functionality, please feel free to lend a hand in getting it documented and tested. > Linux PAM Authentication Provider > - > > Key: KNOX-537 > URL: https://issues.apache.org/jira/browse/KNOX-537 > Project: Apache Knox > Issue Type: Bug > Components: Server >Affects Versions: 0.5.0, 0.6.0, 0.7.0 > Environment: All >Reporter: Jeffrey E Rodriguez >Assignee: Jeffrey E Rodriguez > Labels: knox, pam > Fix For: 0.9.0 > > Attachments: 0001-knox-537-add-pam-authentication-support.patch > > Original Estimate: 168h > Remaining Estimate: 168h > > OS level PAM security provides great interface for authentication and > authorization. For example, sssd provides support for manage Active > Directory nested OU by adjusting ldap_group_nesting_level = 5. Knox > configuration is configured to interact with LDAP directly, but this has two > short cominges. First, hgh volume traffic is likely to make too many > queries to AD without cache. Second, complex logic of LDAP queries can not > map correctly to UserDnTemplate without adding more ldap specific logic into > JndiLdapRealm code and parameters. > Knox can be improved to use PAM to out source complex OS to AD interaction to > sssd. It is possible to implement a shiro PAM plugin to reduce the complex > LDAP logic that is starting to accumulate in Knox. > Looks like there is a least a start for this here. > https://github.com/plaflamme/shiro-libpam4j > libpam4j is available via Maven and uses an MIT license > http://mvnrepository.com/artifact/org.jvnet.libpam4j/libpam4j/1.4 > This might be a great addition to Knox. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jira] [Updated] (KNOX-618) Rewrite function for accessing header values
Thanks Kevin. The issue manifest in the case of pages in a cluster like Yarn Resource Manager UI: http://myrm.com:8088, this page contains links to Yarn Node Managers: http://mynm1.com:8042, http://mynm2.com, http://mynm3.com. The Resource Manager page has links to the Node Managers. We defined two roles RMUI service: RMUI http://myrm.com:8088 NMUI http://mynm1.com:8042 1. During RM UI page output In the page we may have content like embedded script with href= http://mynm2.com:8042 We want to be able to rewrite href=http://mynm2.com:8042 to https://knoxhost:knoxport/gateway/rmui/rm?{host=mynm2.com}?{port=8042 2. When we click https://knoxhost:knoxport/gateway/rmui/rm?{host=mynm2.com}?{port=8042} we apply an IN rewrite rule to access http://mynm2.com:8042. 3. The issue is that on the response to 2, we need to rewrite the href content with the same method we apply in 2., add query params rm?{host= mynm2.com}?{port=8042} e.g. mynm2.com web page href="/logs" we want to apply a rule to include service Host header (Header = mynm2.com ) so href will end up as /logs??{host= mynm2.com}?{port=8042} Then when we user clicks that link it will be rewritten to http://mynm2.com:8042/logs Unfortunately $serviceUrl[NODEUI] would not work since it would have the wrong NMUI host: http://mynm1.com:8042 So something like this would help So I think that KNOX-618 may work for me. I can give a try to the parch you just posted. The other issue I want to discuss is the fact that the some of the user interfaces usually refer to more than one server like in the case of Yarn Resurce manager (refers to nodemanagers). and HBase Master UI (refers also to region servers). Even though I could have created more than one role like : NMUI1 http://mynm1.com:8042 NMUI2 http://mynm2.com:8042 NMUI3 http://mynm3.com:8042 The issue is that during output rewrite there is very little I can do since the information of the namenode hosts is already hardwired by the Yarn RM UI. There has to be a better way to deal with proxying to a Server which refers to other servers. Regards, Jeff Rodriguez On Tue, Mar 29, 2016 at 2:43 PM, Kevin Minder (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/KNOX-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Kevin Minder updated KNOX-618: > -- > Attachment: KNOX-618_001.patch > > > Rewrite function for accessing header values > > > > > > Key: KNOX-618 > > URL: https://issues.apache.org/jira/browse/KNOX-618 > > Project: Apache Knox > > Issue Type: New Feature > > Components: Server > >Affects Versions: 0.6.0 > >Reporter: Kevin Minder > >Assignee: Kevin Minder > >Priority: Minor > > Fix For: Future > > > > Attachments: KNOX-618_001.patch > > > > > > I recently ran into a situation where it would have been useful to have > access to header values in the rewrite rules. In particular it would be > useful sometimes to API version with a header like this. > > {code} > > > > template=""{scheme}://{host}:{port}/api/{$header[version]}/{path}?{**}""/> > > > > {code} > > As implied above the rewrite function plugin model seems like an > excellent way to provide basic access to header information. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.4#6332) >
[jira] [Commented] (KNOX-618) Rewrite function for accessing header values
[ https://issues.apache.org/jira/browse/KNOX-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217037#comment-15217037 ] Jeffrey Rodriguez commented on KNOX-618: Thanks Kevin. The issue manifest in the case of pages in a cluster like Yarn Resource Manager UI: http://myrm.com:8088, this page contains links to Yarn Node Managers: http://mynm1.com:8042, http://mynm2.com, http://mynm3.com. The Resource Manager page has links to the Node Managers. We defined two roles RMUI service: RMUI http://myrm.com:8088 NMUI http://mynm1.com:8042 1. During RM UI page output In the page we may have content like embedded script with href= http://mynm2.com:8042 We want to be able to rewrite href=http://mynm2.com:8042 to https://knoxhost:knoxport/gateway/rmui/rm?{host=mynm2.com}?{port=8042 2. When we click https://knoxhost:knoxport/gateway/rmui/rm?{host=mynm2.com}?{port=8042} we apply an IN rewrite rule to access http://mynm2.com:8042. 3. The issue is that on the response to 2, we need to rewrite the href content with the same method we apply in 2., add query params rm?{host= mynm2.com}?{port=8042} e.g. mynm2.com web page href="/logs" we want to apply a rule to include service Host header (Header = mynm2.com ) so href will end up as /logs??{host= mynm2.com}?{port=8042} Then when we user clicks that link it will be rewritten to http://mynm2.com:8042/logs Unfortunately $serviceUrl[NODEUI] would not work since it would have the wrong NMUI host: http://mynm1.com:8042 So something like this would help So I think that KNOX-618 may work for me. I can give a try to the parch you just posted. The other issue I want to discuss is the fact that the some of the user interfaces usually refer to more than one server like in the case of Yarn Resurce manager (refers to nodemanagers). and HBase Master UI (refers also to region servers). Even though I could have created more than one role like : NMUI1 http://mynm1.com:8042 NMUI2 http://mynm2.com:8042 NMUI3 http://mynm3.com:8042 The issue is that during output rewrite there is very little I can do since the information of the namenode hosts is already hardwired by the Yarn RM UI. There has to be a better way to deal with proxying to a Server which refers to other servers. Regards, Jeff Rodriguez On Tue, Mar 29, 2016 at 2:43 PM, Kevin Minder (JIRA) > Rewrite function for accessing header values > > > Key: KNOX-618 > URL: https://issues.apache.org/jira/browse/KNOX-618 > Project: Apache Knox > Issue Type: New Feature > Components: Server >Affects Versions: 0.6.0 >Reporter: Kevin Minder >Assignee: Kevin Minder >Priority: Minor > Fix For: Future > > Attachments: KNOX-618_001.patch > > > I recently ran into a situation where it would have been useful to have > access to header values in the rewrite rules. In particular it would be > useful sometimes to API version with a header like this. > {code} > > template=""{scheme}://{host}:{port}/api/{$header[version]}/{path}?{**}""/> > > {code} > As implied above the rewrite function plugin model seems like an excellent > way to provide basic access to header information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)