Databases Reference
In-Depth Information
Database root collection
Database
Department collection
Application collection
Document
Element
Figure 11.7
A document store is like a collection of folders, each with its own
lock. To get to a specific element within a document, you need to access all the
containers that hold the element, including the document and the ancestor folders.
your database, but keeping track of each user and their permission gets complicated
quickly, even for a small number of users and records using a
UNIX
permission model.
T
HE
UNIX
PERMISSION
MODEL
First let's look at a simple model for protecting resources, the one used in
UNIX
,
POSIX
, Hadoop, and the eXist native
XML
database. We use the term
resource
in this
context as either a directory or a file.
In the
UNIX
model, when you create any resource, you associate a user and group
as the
owner
of that resource. You then associate three bits with the owner, three bits
with the user, and three bits for everyone that's outside the group. This model is
shown in figure 11.8.
One positive aspect of a
UNIX
filesystem permission model is that they're efficient,
since you only need to calculate the impact of nine bits on your operations. But the
problem with this model is that it doesn't scale, because each resource (a folder or
file) is typically owned by one group, and granting folder rights to multiple groups
isn't permitted. This prevents organizations from applying detailed access-control
Your own
permissions
Your group's
permissions
Everyone else
owner
group
others
The permissions for
anyone outside your
group are
read=true, write=false,
and execute=false.
The letters RWX
are for read, write, and
execute permissions.
RWX
RWX
RWX
110
110
100
Figure 11.8
UNIX, POSIX, Hadoop, and eXist-db all share a simple approach to
security that uses only nine bits per resource. Checks are simple and fast, and
won't degrade performance even when large queries are done on many collections
of many documents.
