[MAPREDUCE-5855] Oozie jobs able to affect container classpath

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 2.2.0
• Component/s: applicationmaster, job submission, mr-am, mrv2

Environment

Centos 6.4

• Assignee: Unassigned
• Reporter: Michael Miklavcic
• Created: 23/Apr/14 21:57
• Updated: 23/Apr/14 22:01

Description

A submitted job is able to affect the container classpath and cause failures at the container level.

The jar spec allows a user to specify a service provider via the Service Loader interface for things like XML implementations. These implementations can be provided by including files in META-INF/services that have a line declaring which implementation should be loaded by the JVM.

I've attached a contrived example that mimics what I witnessed at a client site. They had xalan and xerces jars in an Oozie lib directory as dependencies for a Pig workflow. The stacktrace is also attached.

There is a work-around for this problem - either include all necessary jars, e.g. serializer.jar, in your Oozie workflow lib, or rely on default xml providers. But, is this expected behavior from yarn/map-reduce?