On Sun, Jan 17, 2010 at 2:07 AM, David Goodlad <[email protected]> wrote: > On Sun, Jan 17, 2010 at 8:52 PM, Chris Anderson <[email protected]> wrote: >> I'm thinking maybe: >> >> _local/security:_design/foo >> >> where _design/foo is the name of the ddoc that contains the current >> validation function. >> >> local means it doesn't replicate. hmm, we also need to make sure the >> security doc can only be updated by admins (so maybe _security makes >> sense) >> >> That's nice and clean: >> >> _security/foo to go with _design/foo > > I like the naming, but not the 'only be updated by admins' part. If > there were the concept of admins for individual dbs, I would be fine > with it, though.
There are db_admins. They are the ones who can install ddocs. So it makes sense that they'd have exclusive access to the security object. > >> I have some code open in my editor: couch_db:check_is_admin() >> >> I'm planning to copy this and call it check_is_reader() >> >> So readers is a flat list of names and roles, per db. >> >> If the list is empty, anyone can read. If not, then only readers can >> read. A reader is someone who's name or roles matches the db readers >> list. This means a private db is just a db where the reader list has >> one member, the db-admin. >> >> I think this level of reader ACL is the simplest thing that could >> possibly work, and pretty flexible too. >> >> Everything is readable by server admins. > > Where is this list stored? As a document in the database? The list of db-admins is stored on the database file (as an erlang list). I plan to use the check_is_admin() code as the basis for the reader ACLs. > > Perhaps it could be part of the _security/* namespace - eg _security/readers ? > The current db-admins are not in a document (they are part of the db file) so I don't want to go change all that and I think it's best to have parallel interfaces for db-readers and db-admins. > Dave > -- Chris Anderson http://jchrisa.net http://couch.io
