[ 
https://issues.apache.org/jira/browse/ORC-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16100941#comment-16100941
 ] 

Martin Grund commented on ORC-218:
----------------------------------

Basically, every environment where you don't trust the host system or the 
available system calls are limited. For example, in a Docker environment there 
are security options already today restrict which system calls are allowed. As 
an example, you can't call `nsenter` which is the system call to enter a new 
bind mount environment from with a Docker container to avoid pivoting the root 
to something that the attacker controls.

This optimization is not meant to improve performance, it's simply to avoid 
doing the sytem calls to open(), read() and fstat() files from local disk. Does 
this help?

> [C++] Cache timezone information in the library.
> ------------------------------------------------
>
>                 Key: ORC-218
>                 URL: https://issues.apache.org/jira/browse/ORC-218
>             Project: ORC
>          Issue Type: Improvement
>            Reporter: Martin Grund
>
> Right now, for every lookup of a timezone, the library will go to disk and 
> parse the timezone file. While the results are cached, doing these system 
> calls should be avoided in environments with restricted system calls.
> I prepared a patch that will at build time load all the time zone files into 
> the binary and instead of accessing disk for the TZ information will simply 
> load the buffer from memory. In addition this allows the user to compile the 
> library with a static timezone to be assumed for local use. This comes in 
> handy to avoid yet another set of system calls to assume the local timezone.
> The feature can be controlled using the following CMake flags
> * NO_EMBEDED_TZ_DB - to turn it off, by default is on
> * STATIC_TZ=VAL - where val is a name of a timezone.
> I'll create a PR for code-review.
> Would be great if you could consider this patch.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to