[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)
