monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] No Security for "monotone read": Why?


From: Richard Levitte - VMS Whacker
Subject: Re: [Monotone-devel] No Security for "monotone read": Why?
Date: Wed, 04 Jan 2006 20:23:09 +0100 (CET)

In message <address@hidden> on Wed, 4 Jan 2006 10:23:29 -0800 (PST), Logan 
Sackette <address@hidden> said:

lsackette> Thanks for Monotone.  I just noticed that I can add
lsackette> keys to my mtn db without a password.  I was just
lsackette> wondering, why that is allowed when it seemed like
lsackette> just about anything else about mtn is about security.

A public key doesn't have a password.  Why would you want to insert
someone else's private key?

Either way, you need to protect the database itself appropriately.
After all, it's simply a SQLite file, so anyone that has access to the
database could just as well insert the key records directly by using
the SQLite shell or something like that.

lsackette> I guess I am just thinking of a possibly breach where
lsackette> by someone who is not suppose to have access to a db
lsackette> might insert their key.  Or that isn't enough to gain
lsackette> access without some modification to the permit files?

Depends.  If the permit files give write access to everyone, you're
screwed.  If it isn't, the identities of each key that should have
access must be specified.  Without that, there is no access through
monotone.

Again, you really want to protect your database(s).

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis




reply via email to

[Prev in Thread] Current Thread [Next in Thread]