Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ammulder@gmail.com designates
 64.233.162.200 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=nq6mj+kCH9KfBEXpDiKb0zypv/WqXrVK/pXwqSQzgtHa+pZKrqY7Bje9wL/ZNyMp5JRf5b6HBwYlYEx/INVXdv39mEBjtz2rp97VZ9lbi/LcYzjgmsF0dV5G8h1JbHFRTvrHILJtDxwJW5CJ+xUaV3GskloMt6SKYlysYVtAmeU=
Message-ID: <74e15baa0511180914u194a5764gd00b85dbb98d6031@mail.gmail.com>
Date: Fri, 18 Nov 2005 12:14:45 -0500
From: Aaron Mulder <ammulder@alumni.princeton.edu>
Sender: ammulder@gmail.com
To: dev@geronimo.apache.org
Subject: Re: Constructing deployment plans from Configuration GBeanData
In-Reply-To: <FA3887A4-A687-4E62-BC1C-AD0711EA7186@iq80.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <22d56c4d0511160410t1d099c47g6522e1607ff56909@mail.gmail.com>
	 <5fe06e27c9131035126fcf8cb7075ddc@yahoo.com>
	 <22d56c4d0511170445t5969d296we2663aae3a3c4b2a@mail.gmail.com>
	 <93f2c9dc32adcf68c02aa2c99a928089@yahoo.com>
	 <22d56c4d0511172121ya9cb05eg453ec075f006656f@mail.gmail.com>
	 <8188ba8dc92532609f153bd1272ea18b@yahoo.com>
	 <74e15baa0511172330k2028e644s612d4babfe0f13e2@mail.gmail.com>
	 <FEBE5C5B-7C26-454D-AE45-5244F07DE1F5@iq80.com>
	 <FA3887A4-A687-4E62-BC1C-AD0711EA7186@iq80.com>

On 11/18/05, Dain Sundstrom <dain@iq80.com> wrote:
> Wait a sec.  We are worried about an administrator that has access to
> the console from seeing a password embedded an a configuration file?
> The admin can deploy applications, which could easily just scan for
> passwords in memory or on disk.  Anyone with access to this console
> is "root" for the geronimo instance.

Yeah, that's why I waffle.  But for example, if you look at a database
pool in the console, it uses a password field and doesn't show you the
plain text.  It's not that you can't get around this (via, say, view
source, if not writing your own code to inspect the GBeans), it's that
I'm not sure I like flagrantly popping up stuff with passwords right
there.  You know, shoulder-surfing, or whatever.

Erin says some peolpe argue that no security is better than something
weak that gives you a false sense of security, but I also think
there's a place for defending against the casual observer.

Forget about the console for a sec.  How many people will think to
make their config store directory non-world-readable?  Sure you could
write some code to deserialize the stuff in there today, but if anyone
with an account on the box can just view a plain-text plan out of the
config store with the passwords, that's really "no security".  (And
since every connector has different config params it's not so easy to
just mask out the password in every file we copy in there, though it
would be a good start to do it for any config-param where
name.toLowerCase().indexOf("password") > -1.)

Aaron

> On Nov 18, 2005, at 8:57 AM, Dain Sundstrom wrote:
> > If we are the ones copying over the plans, why not have the
> > deployment code for the module, simply remove passwords from the
> > file before copying it.  Alternatively, we could choose to not copy
> > over the plan for connectors.
> >
> > -dain
> >
> > On Nov 17, 2005, at 11:30 PM, Aaron Mulder wrote:
> >
> >> Note that JSR-77 requires us to expose the J2EE DD through our module
> >> beans, and it may make sense to provide a similar hook for the
> >> Geronimo plan.  That would make it easy to implement nicely in the
> >> console, certainly.
> >>
> >> However, I agree that it's important to be able to suppress showing
> >> plans, particular for connectors where they're likely to have
> >> passwords in them.  Sure, you only see that if you got into the
> >> console/MEJB/whatever to begin with, but still...  I'm not sure what
> >> to say about the default behavior.  I thought this was such a cool
> >> idea until I thought about the password issue, but if we make hiding
> >> the plans the default, then it's not all that useful a feature.  I'm
> >> waffling.
> >>
> >> Aaron
> >>
> >> On 11/18/05, David Jencks <david_jencks@yahoo.com> wrote:
> >>>
> >>> On Nov 17, 2005, at 9:21 PM, Vamsavardhana Reddy wrote:
> >>>
> >>>>
> >>>>
> >>>> On 11/17/05, David Jencks <david_jencks@yahoo.com> wrote:
> >>>>> On Nov 17, 2005, at 4:45 AM, Vamsavardhana Reddy wrote:
> >>>>>
> >>>>>> If deployment plans are inside the archive (ear, war, etc.)
> >>>>>> they can
> >>>>>> be obtained from config-store. If the deployment plan is
> >>>>>> supplied as
> >>>>>> an external file to the deployer and if the original file is not
> >>>>>> available, the only way to get any information on the
> >>>>>> configuration
> >>>>> is
> >>>>>> from the Configuration GBeanData obtained from the kernel at
> >>>>>> runtime
> >>>>>> or from deserializing config.ser files under config-store. For
> >>>>>> analyzing any problems after an application is deployed,
> >>>>>> deployment
> >>>>>> plans will certainly be helpful.
> >>>>>
> >>>>> If you think this is really valuable information, I think a better
> >>>>> approach is to store the plan(s) in a known location in the
> >>>>> configuration so they may be retrieved directly.
> >>>>  I thought of this as an option because it will really simplify
> >>>> a lot
> >>>> of things, and I can avoid writing a configuration decompiler :o).
> >>>> But, then will there be any instances where the user will not
> >>>> want the
> >>>> deployment plan to be stored in the server as is? Will "not want to
> >>>> store the deployment plan in the config-store" be ever a users'
> >>>> reason
> >>>> for supplying deployment plan as an external file to the deployer?
> >>>
> >>> Well, I think there will be few cases where the original deployment
> >>> plan will be unavailable from other sources, and I don't
> >>> particularly
> >>> like including it in the configuration.  However, I don't think this
> >>> has much to do with the desirability of keeping the plan separate
> >>> from
> >>> the module you are deploying: I think this is always a good
> >>> idea.  I do
> >>> think that some people will want to conceal their plan and if we do
> >>> provide a way to include it in the configuration this choice must be
> >>> optional.
> >>>
> >>> thanks
> >>> david jencks
> >>>
> >>>
>
>