First a little (tentatively) suggested
terminology---translation of (tentatively) I stand
behind it until I begin to suspect I've made a mistake and then I
change sides ;-) :
1) A mask consists of a set of prescriptions (trying
to avoid rule) which defines a
subset of permissible functionality for a file system.
2) The permissible functionality of a file system is roughly
speaking, the ACLs
for all the objects in the file system.
Actually, I think this is a good place to start, because the type
"permissible
functionality" is in fact what the mask is applied to and what is
returned.
Grant you evaluation is done lazily as the execution of an
application requires it.
3) A user and group instantiated mask forms an operational set of
functionality.
What is important here is to recognize that a given executable may
have
different apparent functionality based on who is running it.
To make this concept clearer, consider the possibility that group
write access
to a file might be elided (masked away) by the some prescription
for a user
who otherwise might have add access---but the user's privileges
are limited
by the executable.
Hans Reiser wrote:
It is
very important that we have something simple that reuses code for this
purpose, and it also needs to be scalable. That is, we need to be able
to determine in insignificant time whether a file passes through a mask
consisting of a million files.
A million files or a million rules? A single rule may give access to a
million files and
require only constant time to evaluate.
One
approach would be to use a format similar to that for chroot, that is,
to keep the format we use for directory trees now, and use it for
storing the mask. This raises the question: how would the format for
the mask differ from that of the underlying filesystem.
Another approach is to use stem compressed names, or some other unique
within the fs format for the mask.
Can you elaborate on this for a newbie
We need to be able to support specifying a mask that allows any file
within a given directory to be visible. That is, we need to support
dirname/* but we don't yet need to support dirname/foo.*
NB. Hans and I had discussed limiting access to 'hidden files'
informally: '..' in particular needs some
special attention although it would be best not to have a special case
if we can avoid it.
We probably don't want to allow symbolic links to be followed unless
where they point to is within the mask.
Agreed.
I want
minimal code but I want it to be treelike in its performance
scalability.
Ideas?
Well, for the moment only more questions:
Suppose we have a file system and a mask. If we were to create a
chroot by copying just
the file system accessible through the mask and run the application in
that environment
would the semantics of running the application on the original file
system with the mask
by equivalent. By equivalent I mean no observable difference in the
instructions executed
at the user level or the output generated.
Does the question make sense?