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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
On 11/18/05, Dain Sundstrom <[EMAIL PROTECTED]> 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
