rediscoveries

Saturday, May 9, 2015

aha!

Some command-line tools produce nicely coloured output when running on ANSI terminals. However, when saving output of these tools into a text file for sharing, these colors are often lost, either due to copy/pasting that is not aware of colour codes or because the tools themselves detect the redirection and then output plain text only :)

In cases where tools preserve the ANSI colour codes on redirection, tiny aha (ANSI HTML Adapter) tool written by Alexander Matthes can be helpful when sharing the output with others. Its available from Debian packages or as source code at GitHub.

Its HTML output will look like below—this particular output example is from command which red-coloured output parts should catch recipient’s attention.

sslscan example.org:443 | aha --title "sslscan example.org:443" > output.html


Version: -static
OpenSSL 1.0.1m-dev xx XXX xxxx

Testing SSL server example.org on port 443

  TLS renegotiation:
Secure session renegotiation supported

  TLS Compression:
Compression disabled

  Heartbleed:
TLS 1.0 not vulnerable to heartbleed
TLS 1.1 not vulnerable to heartbleed
TLS 1.2 not vulnerable to heartbleed

  Supported Server Cipher(s):
Accepted  SSLv3    256 bits  DHE-RSA-AES256-SHA
Accepted  SSLv3    256 bits  AES256-SHA
Accepted  SSLv3    128 bits  DHE-RSA-AES128-SHA
Accepted  SSLv3    128 bits  AES128-SHA
Accepted  SSLv3    128 bits  RC4-SHA
Accepted  SSLv3    128 bits  RC4-MD5
Accepted  SSLv3    112 bits  EDH-RSA-DES-CBC3-SHA
Accepted  SSLv3    112 bits  DES-CBC3-SHA
Accepted  TLSv1.0  256 bits  DHE-RSA-AES256-SHA
Accepted  TLSv1.0  256 bits  AES256-SHA
Accepted  TLSv1.0  128 bits  DHE-RSA-AES128-SHA
Accepted  TLSv1.0  128 bits  AES128-SHA
Accepted  TLSv1.0  128 bits  RC4-SHA
Accepted  TLSv1.0  128 bits  RC4-MD5
Accepted  TLSv1.0  112 bits  EDH-RSA-DES-CBC3-SHA
Accepted  TLSv1.0  112 bits  DES-CBC3-SHA

  Preferred Server Cipher(s):
SSLv3    256 bits  DHE-RSA-AES256-SHA
TLSv1.0  256 bits  DHE-RSA-AES256-SHA

  SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
RSA Key Strength:    2048

Subject:  example.org
Altnames: DNS:example.org, DNS:www.example.org
Issuer:   COMODO RSA Domain Validation Secure Server CA


Sunday, December 28, 2014

Quick 2-tuples in Java

For cases one does not want or need (because it would never find reuse!) to create wrapper class for pairing two values of any types (a 2-tuple) in Java, Map.Entry public inner interface in java.util.Map container can be acceptable alternative. Code relying on java.util.Collections.singletonMap (constant additional space use!) to return a pair from Java method can be written as such:

// returns pair (2-tuple)
private Map.Entry<Integer, Record> bar() {
  // ... recordCount and record created
  return Collections.singletonMap(recordCount, record).entrySet().iterator().next();
}

// 2-tuple extraction with getKey()/getValue()
public void foo() {
  Map.Entry<Integer, Record> pair = bar();
  Integer recordCount = pair.getKey();
  Record record = pair.getValue();
  // use paired values ...
}

Tuesday, July 29, 2014

Locales in Liferay

I wanted to configure the languages available in Liferay 6.2 runtime interface site settings (Site Administration → Configuration → Site Settings → Display Settings → Language) to include Russian and Azerbaijani — but these were not even listed among available languages. From portal source I verified that language pack for Russian indeed exists (not for Azerbaijani though!).

Having had a look at portal.properties gives a hint that interface languages in Liferay runtime depend on locales.enabled setting, which can be overriden in one of the Liferay configuration files (reading order: portal.properties, portal-bundle.properties, portal-ext.properties & portal-setup-wizard.properties). So e.g. locales.enabled=en_US,ru_RU in portal-ext.properties will do the trick for making Russian locale available, for Azerbaijani, one would need to start translating.

And later I found that available locales can also be set from Control Panel → Configuration → Portal Settings → Display Settings → Available Languages :)

Friday, July 18, 2014

Liferay 6.2 archetypes

Maven (build tool and a Trickster) provides several Liferay specific archetypes with com.liferay.maven.archetypes archetypeGroupId. Some of these are tied to MVC frameworks to be used in Liferay portlet (e.g liferay-portlet-jsf-archetype), others assembled for more generic functionality. Sample command line to generate Liferay portlet project structure without any MVC specifics added:

mvn archetype:generate \
     -DarchetypeGroupId=com.liferay.maven.archetypes \
     -DarchetypeArtifactId=liferay-portlet-archetype \
     -DarchetypeVersion=6.2.10.6 \
     -DgroupId=thecompany.com \
     -DartifactId=company-portlet-one \
     -Dversion=0.1-SNAPSHOT \
     -DinteractiveMode=false

The list of all available Maven archetypes can be seen with: mvn archetype:generate command. Following MVC agnostic archetypes are available in com.liferay.maven.archetypes group.

  1. liferay-ext-archetype — for creating customizations as Liferay extension, also called ext plugin. With ext plugins Liferay core functionality can be replaced with modifications separate from Liferay's code. Jamie L Sammons writes: Liferay Ext Plugins are often considered a last resort in the Liferay Plugin world due to the complexity and the lack of hot deploy as well as the inability to remove them once they are deployed.

  2. liferay-hook-archetype — for Liferay customization, a hook has advantage of hot deploy. Web resources, JSPs, portal services, etc can be overridden with hooks. Hooks can also be defined in portlets.

  3. liferay-layouttpl-archetypelayout templates allow definition of new page layouts, embedding commonly used portlets in layouts, specifying CSS, etc.

  4. liferay-portlet-archetype — minimalistic Liferay portlet to be deployed in portal.

  5. liferay-servicebuilder-archetype — to generate a basic service layer. It comes with promise of CRUD and SOAP all in place for the entities.

  6. liferay-theme-archetype — Liferay theme plugin archetype for user interface customization of sites in Liferay.

  7. liferay-web-archetype — creates a minimal web application skeleton, Liferay specific addition being WEB-INF/liferay-plugin-package.properties file, allowing to manage that application from Liferay Control Panel.

Saturday, July 12, 2014

Liferay Editions

Ambitiously named Liferay provides open-source "enterprise" Java portal environment for JSR-286 portlets.

Current Liferay version is 6.2, distributed in two editions:

  • Community Edition (CE)
  • Enterprise Edition (EE)
Birdview comparison of Liferay editions is presented at: http://www.liferay.com/downloads/liferay-portal/overview. EE is built on LGPL code of CE edition and additions include "Emergency Hot Fixes", "Consolidated Service Packs", wider selection of ready-made components (web-forms, workflows, systems integration) and various support options depending on service levels. Source code of EE is available with subscription. In the EE FAQ, there is a promise that each EE version will be supported for minimum of 4 years.

Liferay has partner programs for redistribution, support and service. Componence is one of the partners that has provided more detailed list of EE features.

Pricing of Liferay EE is opaque, their get pricing link opens up a form requesting all kinds of information about the potential client, including short description of project use case, including an estimated scale (total users, concurrent users, integrations and redundancy planned) plus any current infrastructure estimations for OS, DB, IdM, integration.

Friday, March 7, 2014

SVN diff of the day

Shell script to first show the list of modified files and then the corresponding diffs:

#!/bin/sh
TODAY="date +%Y-%m-%d"
DIFFCMD="svn diff -r{`$TODAY -d yesterday`}:{`$TODAY`}"
$DIFFCMD --summarize        # file list report
$DIFFCMD --no-diff-deleted  # diffs

Wednesday, March 5, 2014

Privileged ports, Linux capabilities and Java

Under Unices (including Linux), running a listening service on low numbered privileged TCP ports (< 1024) can usually only be done by root (superuser). This does not necessarily mean that service needs to run with effective user id of root, but at service port binding time, user running the program needs to have sufficient privileges. As lot of low numbered ports are commonly used for many standard services (HTTP is usually over port 80 and HTTPS port 443, etc), the notion of privileged ports can be considered "security through convention" approach, preventing random user with UNIX shell account popping up some apparently "official" service. On the other hand, requirement for privileged account can become a security issue, if the program that needs to be run on privileged port is in some aspects untrusted.

privbind/authbind

Debian packages include privbind utility that allows to execute application as an unprivileged user with extra privilege of binding to reserved ports. Its manual is contradictory, specifying both that:

  • privbind has no SUID parts, and runs within the confines of a single process
  • privbind works by starting two processes. One drops privileges and runs (exec(2)) the command, the other remains as root.
Contradictions aside, privbind is unable to work with many current Java Virtual Machines (JVMs), as it is "using LD_PRELOAD to intercept every call to bind(2) made by the program"1, while JVM implementations can and do binding calls directly to kernel. If it works, usage can be as easy as: "privbind path_to_binary".

Similar package available on Debian is authbind, also using LD_PRELOAD mechanism and thus suffering from the same limitations.

setcap + chrpath

However, on Linux kernels with capabilities support (2.2+), using per-thread NET_BIND_SERVICE capability can be used to run service on privileged port without runtime superuser privileges. This capability can be enabled with setcap "eip" flags (effective, inheritable and permitted, execute as root), e.g. on Java binaries:

setcap cap_net_bind_service=+eip $JAVA_HOME/bin/java
setcap cap_net_bind_service=+eip $JAVA_HOME/jre/bin/java

While necessary, setcap might not be sufficient (as unprivileged user):

java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
Examining the java binary with readelf shows:
xyz@sdk$ readelf -d java
Dynamic section at offset 0x71c contains 28 entries:
  Tag        Type                         Name/Value
 ... skipped ...
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000e (SONAME)                     Library soname: [lib.so]
 0x0000000f (RPATH)                      Library rpath: [$ORIGIN/../lib/amd64/jli]
According to thread in openjdk distro-pkg-dev list, glibc disallows relative paths and $ORIGIN expansion when running binary with capabilities as ordinary user (for security reasons). One solution to that is to change the RPATH encoded in ELF binary to absolute path. From Debian packages chrpath can be used for this:
chrpath -r $JAVA_HOME/lib/amd64/jli/ $JAVA_HOME/bin/java
chrpath -r $JAVA_HOME/jre/lib/amd64/jli/ $JAVA_HOME/jre/bin/java

setcap + patchelf

Changing RPATH can also be done with patchelf, not currently included in Debian packages. Sylvain Duloutre's blog post describes granting identical port binding capabilities to JVM binaries with setcap and patchelf, with RPATH change performed like this:

patchelf --set-rpath $JAVA_HOME/lib/amd64/jli $JAVA_HOME/bin/java
patchelf --set-rpath $JAVA_HOME/jre/lib/amd64/jli $JAVA_HOME/jre/bin/java

NB!

Granting capabilities to (JVM) binaries can introduce security concerns and should only be done where access to such binaries is suitably restricted.


1 privbind-devel: privbind not working with Java