couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filipe David Manana <fdman...@gmail.com>
Subject Re: /_all_dbs and security
Date Mon, 01 Mar 2010 15:50:40 GMT
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."

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message