incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <dam...@apache.org>
Subject Re: /_all_dbs and security
Date Mon, 01 Mar 2010 15:45:36 GMT
I don't think end users need a list of dbs they can access on the server. Think the simplest
answer is to only support _all_dbs operation for admins and be done.

-Damien


On Mar 1, 2010, at 1:40 AM, Brian Candler wrote:

> On Mon, Mar 01, 2010 at 09:55:46AM +0100, Filipe David Manana wrote:
>>> The reason for no storing _security as a doc is an optimization. So we
>>> extend that optimization, and have something like a  security_changed event
>>> for a db, that the _dbs database can react to. The model isn't different
>>> from subscribing to _changes, it'd just be a separate code path.
>> 
>> That's a good idea (both simple and more efficient).
>> 
>> The only issues left are the cases where the user adds a new DB file
>> (possibly coming from other server for e.g.) into the DB dir, deletes a DB
>> file or replaces a DB file with an old version (a backup whose update seq
>> number is from the past).
> ...
>> Do you think this would add too much overhead or it could be a somewhat
>> "light" approach? Or better, do you have a better idea for it?
> 
> Just as an idea, you could just turn this on its head. Suppose _dbs was the
> primary source of information; then the _security record within the database
> is just a cached copy of that.  It's easy enough to take a _changes feed
> from _dbs to update this cache.
> 
> But in that case, the cache would be better kept in RAM, rather than within
> the database file.
> 
> After all, CouchDB already keeps a cache of open database filehandles,
> doesn't it?  So you could read the security information from a regular
> document (an "expensive" operation) when you open the database, and then
> just continue to use that version thereafter.  You'd invalidate the cache if
> the corresponding _dbs object is updated.
> 
> However this leaves the following issue: what if the database file is
> renamed on disk, or disk-copied to a different system which happens to have
> an existing _dbs entry for that name?
> 
> I think the best solution is for the _dbs database to be indexed by uuid. 
> But to make this work efficiently, the database file *on disk* should also
> be named by its uuid, rather than the database name.  That's probably too
> big a change to swallow at this stage.
> 
> But it does have some other side benefits (such as being able to "rename" a
> database instantly without touching the filesystem, and being able to
> automatically spread a large number of databases across directories without
> forcing the user to use database names like 00/xxx, 01/yyy, 02/zzz etc)
> 
> Regards,
> 
> Brian.


Mime
View raw message