Mailing-List: contact dev-help@brooklyn.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of aled.sage@gmail.com designates
 74.125.82.51 as permitted sender)
Message-ID: <53EC960E.60703@gmail.com>
Date: Thu, 14 Aug 2014 11:57:18 +0100
From: Aled Sage <aled.sage@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: dev@brooklyn.incubator.apache.org
Subject: Re: web-console security: use hashed passwords in brooklyn.properties
References: <53E4DCE2.4050308@gmail.com> <53E8A4DA.1010706@cloudsoftcorp.com>
In-Reply-To: <53E8A4DA.1010706@cloudsoftcorp.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,

Brooklyn master now checks if ~/.brooklyn/brooklyn.properties (or 
whatever you override it with on the launch command line) has 
permissions like 600 (or 700 or 400). Brooklyn will fail to start 
otherwise, giving a nice error to tell you why.

Note that we won't check these permissions on Windows currently. You'll 
get a log.debug telling you that we couldn't check.

Aled


On 11/08/2014 12:11, Alasdair Hodge wrote:
> Enthusiastic "yay!" for hashed, salted passwords :o)
>
> Also +1 to enforcing tighter access control for the properties file at 
> runtime. Will require a Windows equivalent, of course, but checking 
> for *00 flags on posix systems is a great start. I expect we want 
> "strict" behaviour only in the launcher, and that unit tests, etc, 
> don't need to care?
>
> As for the --stdin thing for generate-password, I must admit I'm 
> sympathetic to the "don't do that" argument in the links you posted. 
> If stream hacks are required only to test the generator then it's 
> probably no biggie, but making recommendations to end-users that go 
> against the grain of established unix security best practices gives me 
> pause.
>
> A.