geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sisson <jrsis...@gmail.com>
Subject Re: Constructing deployment plans from Configuration GBeanData
Date Sat, 19 Nov 2005 07:15:23 GMT
You could look at how ant does it.  I am guessing using exec(). 
http://ant.apache.org/manual/CoreTasks/chmod.html

John

Aaron Mulder wrote:

>On 11/18/05, Dain Sundstrom <dain@iq80.com> wrote:
>  
>
>>In 1.1+ we could change the config store to set the file permissions
>>on the directories it creates.
>>    
>>
>
>How can you do that from Java?
>
>Aaron
>
>  
>
>>On Nov 18, 2005, at 11:05 AM, Kevan Miller wrote:
>>
>>    
>>
>>>On 11/18/05, Aaron Mulder <ammulder@alumni.princeton.edu> wrote:
>>>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
>>>
>>>I think you raise a couple of good points about 1) protecting
>>>config-store directory and 2) masking sensitive configuration data.
>>>I ran into both of these looking at your recent issue
>>>http://issues.apache.org/jira/browse/GERONIMO-1135 (keystore and
>>>passstore passwords are available in System properties).
>>>
>>>BTW, another potential exposure of sensitive data are the admin ids
>>>and passwords stored in a .geronimo-deployer directory by your
>>>recent "login" addition to deployer.
>>>
>>>config-store and .geronimo-deployer are documentation/good practice
>>>issues which shouldn't be too hard to document (but easy to ignore/
>>>miss...). Protecting sensitive data in the runtime seems like a
>>>harder task. Something we can address in V1? Something we must
>>>address in V1? Any other security-related problems?
>>>      
>>>
>>-dain
>>
>>    
>>
>
>  
>


Mime
View raw message