Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Subject: Re: Getting application root path before servlet is initialized?
To: Tomcat Users List <users@tomcat.apache.org>
References: <CAJtcoLasrtjDqjmX7Fp3yj2srU_pQYW=SOEyoDs+g_F7hSEVQQ@mail.gmail.com>
 <1d5cc2b4-9a16-0ce8-383e-69a06ab5f78d@apache.org>
 <CAJtcoLZ5e=c+DobXKYvL_8rbpSF3KZqDsKZTDCwori5en8HP0g@mail.gmail.com>
From: =?UTF-8?Q?Daniel_K=c3=bcppers?= <daniel@tetralog.com>
Organization: Tetralog Kunststoffrecycling e.K.
Message-ID: <03d5a55f-7a1b-d713-456e-2dc3838ad1b8@tetralog.com>
Date: Wed, 22 Feb 2017 12:26:13 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <CAJtcoLZ5e=c+DobXKYvL_8rbpSF3KZqDsKZTDCwori5en8HP0g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
archived-at: Wed, 22 Feb 2017 11:26:24 -0000

Am 22.02.2017 um 11:19 schrieb Martin Knoblauch:
> On Tue, Feb 21, 2017 at 8:55 PM, Mark Thomas <markt@apache.org> wrote:
>
>> On 21/02/2017 13:31, Martin Knoblauch wrote:
>>> Hi,
>>>
>>>   is there a way to find the absolute path of the application root before
>>> the servlet is initialized?
>>>
>>> Alternatively: is there a way to defer the initialization of a datasource
>>> until the servlet is initialized?
>>>
>>> Background: I have extended "org.apache.tomcat.jdbc.pool.
>> DataSourceFactory"
>>> to automatically set credentials so that they are not stored in the
>>> "Catalina/localhost/XXX.xml" file. Instead they are taken from encrypted
>>> values in a file below the application root. Works fine if I know that
>> path
>>> at "createDataSource" time.
>> And the decryption key for that file is stored where?
>>
>> https://wiki.apache.org/tomcat/FAQ/Password
>>
>>
>   Thanks for link. It clearly reflects my opinion as well, but the customer
> demand is:
>
> - no plain-text credentials (Big multinational company security policies -
> fight them if you need the fun). And yes, this is all about making auditors
> happy
> - minimize the locations where credentials are stored. This is only lightly
> related to the decrypt issue. Having to store identical stuff in more than
> one place is opening up all other sorts of practical issues
>
>   So, yes - any mechanism that can decrypt needs to store the key somewhere
> and this just shifts away the problem from securing one item to securing
> another one. In my case the application (that I will not reveal here)
> stores encrypted DB credentials in its configuration and provides an API to
> retrieve them decrypted. I guess, the key is somewhere in the source code
> (likely obfuscated to prevent casual hacking by debugging). the less I know
> ... :-)
>
>> In order to avoid hard coding that path, I need a programmatic to find
>> that
>>> value. Unfortunately the datasource is initialized before the servlet, so
>>> "getRealPath()" is not working yet.
>>>
>>> Environment is Tomcat 8 plus JDK 8. Plus an commercial application that I
>>> do not want to name :-)
>> Ignoring what I suspect is a fundamental flaw in this plan, you probably
>> want a ServletContextListener and contextInitialized()
>>
>>
> Thanks again for the hint. Will have a look. In the meanwhile  I found a
> way by looking at
>
> this.getClass().getProtectionDomain().getCodeSource().getLocation().getPath();
>
> Adding some assumptions about the classpath (which are required to be true
> in this whole context) this gives me the needed information :-)
>
> Thanks
> Martin
>
>> Mark
>>
>>
I could imagine that the use of a secure key-value store would be 
helpfull in this scenario.
vault is a great solution for this. quick googling [1] brings a tomcat 
implementation for vault.
If youre not allready familiar with vault, give it a try [2].

Daniel

[1] https://github.com/januslabs/tomcat-vault
[2] https://www.hashicorp.com/vault.html

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org