Re: [stellation-res] Command line configuration specification

["Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>]

On Mon, 2003-01-13 at 14:42, Jonathan Gossage wrote:
> > - I'm pretty sure that MySQL has a notion of a database name, and so
> >   there should be an option to specify that.
> 
> If I remember correctly, this is managed within the Mysql configuration
> files and is not exposed to the JDBC driver, but I will double check this.

I can't find my MySQL manual right now (it must be at home)... But I
thought you could create more than one database, and expose all of
them to JDBC. I think there is a default database, which is what
you get connected to when you don't specify a dbname, but I'm pretty
sure there's also a way to connect to other DBs. 

> > - In the Server-connect element of the config file: the intention is
> >   to have a server listen on a single port: the login and subscription
> >   process is how we distinguish a child server from a client. So there
> >   shouldn't be a distinct port for accepting connections from children.
> 
> Is there any specs on this yet?

No, not yet. The basic concepts are described in some of the papers, but
the details have never been set down. 


> > - I'm a bit skeptical about encrypting the database admin password. The
> >   question is, how do we encrypt it? I can't think of a way that won't
> >   be easy to reverse engineer and determine the password. (For example,
> >   we could hardcode a password when we compile the server, but then that
> >   password can be found by looking at the .class file. We could encrypt
> >   that, but then it's still not too hard to find a way to figure out how
> >   we did that, and get *that* password. It seems to me that ultimately,
> >   unless we require the administrator to specify a password when they
> >   start the server (which precludes automatically starting servers),
> >   then we are ultimately relying on the fact that the config file is
> >   secured. Putting the encryption in is giving people a false sense of
> >   security that they don't really need to be so careful of protecting
> >   their server config file.
> 
> It only provides light security. All it can do is prevent browsing
> plain-text files to prevent casual snooping. In general it is not possible
> to provide any serious security in environments where debuggers or other
> observational tools can be run. That being said, 90% of attempts to crack
> security can be stopped by simple measures such as not leaving plain-text
> passwords lying around.

And even more by using appropriate file protection, so that people
can't snoop the files without already having compromised your system
so badly that nothing is safe anyway. 

Sorry, it's the unix snob in me;
I always forget that the majority of users out there are using a system
where file access security doesn't really work. In Linux, you just put
config files like that in a directory that users can't access. For
example, using root privs, I can figure out the passwords for encrypting
the password table in postgres in about five minutes. A user without
root privileges simply can't get to the files that they would need to
see to do it.

I don't object strongly to encrypting the password; I'll just insist on
making the docs very clear that the encryption of the password is
sufficiently weak that it should not be considered sufficient security
unless the file is also protected.

	-Mark


-- 
Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center  
*** The Stellation project: Advanced SCM for Collaboration
***		http://www.eclipse.org/stellation
*** Work: mcc@xxxxxxxxxxxxxx/Home: markcc@xxxxxxxxxxx