couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Scheliga <ma...@sourcegarden.de>
Subject Re: /_all_dbs and security
Date Mon, 01 Mar 2010 22:11:05 GMT
Why do you need this for DB-Admins? Is that an application-level  
requirement?
Why don't maintain those informations in an extra database?

greetz
mario

Am 01.03.2010 um 16:50 schrieb Filipe David Manana:

> I assume your talking about server admins (those listed in the .ini  
> file),
> right? If you're talking about DB admins, than the problem is the same
> (reading the _security object from each db file).
>
> On Mon, Mar 1, 2010 at 4:45 PM, Damien Katz <damien@apache.org> wrote:
>
>> 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.
>>
>>
>
>
> -- 
> Filipe David Manana,
> fdmanana@gmail.com
> PGP key - http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC569452B
>
> "Reasonable men adapt themselves to the world.
> Unreasonable men adapt the world to themselves.
> That's why all progress depends on unreasonable men."


--
Sourcegarden GmbH HR: B-104357
Steuernummer: 37/167/21214 USt-ID: DE814784953
Geschaeftsfuehrer: Mario Scheliga, Rene Otto
Bank: Deutsche Bank, BLZ: 10070024, KTO: 0810929
Schoenhauser Allee 51, 10437 Berlin


Mime
View raw message