Hans Reiser wrote:
George Beshers wrote:
David Dabbs wrote:
In the original proposal posted to the list Hans (I think) referred
to viewprinting as "chroot on steroids." Let's assume that the mask
creation tools deliver on making viewprint creation and maintainance
very easy/painless for admins. In what way will viewprinting be more
secure than chroot?
Basically, chroot as I at least normally use it, has a lot of baggage
in terms of
disk consumption that we are planning to avoid by creating a view
rather than
a copy.
Chroot lacks fall through points.
Other than saving disk space is this important?
Are you thinking about multiple processes, with different views, but
sharing a few "resources", i.e., files of one form or another as part of
a long term vision?
Hans, in your preferred approach you referred to "a format that is
as if it is a subdirectory of the masked executable." Did you have
in mind checking for something like /usr/bin/fooprocess/metas/mask
when exec() loads the exe, and if this exists then the files rooted
in this directory would be set as the process's root filesystem?
Are masks capable of explicit exclusion as well as inclusion?
If the answer is 'Yes,' then what are your thoughts as to how this
might be accommodated when your main tool is reiser4's semantic tree
layer? Inclusion would be straightforward -- if the directory exists
or the name exists within the directory then fall through. But
exclusion? If you are limited to the semantic layer, then there's no
stat node with which to play tricks.
I think the correct answer is "anything not explicitly included is
excluded"
or on the other side of the looking glass "anything not explicitly
excluded
is included".
As a user friendly interface both should be supported and the
"compilation"
layer handle the conversion.
Maybe I am not understanding the question.
clearcase has an exclude operation for its view specifications.
I don't remember it being more than the boolean complement of
a (potentially much more complex) include operation.
So good UI point but I don't think extends the semantics?
I wonder if it would be feasible if masks only specified exclusions?
If, for instance, the mask wanted to exclude /foo/*, then the
directory foo would exist (in the mask semantic tree). To exclude
/etc/passwd, passwd would exist in the directory /etc. Since you're
already going to need to preempt dcache searches (aren't you?) you
can insert a search of the mask tree. If the search fails, then it
is not excluded and the request falls through to normal VFS
handling. In the /etc/passwd case above, it would find /etc/passwd
and so the file is excluded. Processing would stop there, returning
some error. How does this sound? I need to sleep on this, because it
is very late here.
At this time I think feasible is true and useful is an open question.
To address the useful I find that known/desirable use-case scenarios
get the most discussion.
To give a couple of examples:
1) A given process (say a restricted shell) can not exec() an
executable with the set-uid bit on.
- directly
- indirectly (e.g., via bash)
2) Apache can only create/write files in /var/web/incoming.
- files created or modified can not have any execute bit set
and executing chmod is excluded.
this protection happens while traversing the mask or at the fall
through point. Hmmm, we need to accumulate a set of permissions that
apply to something that are specific to how we got there. That could
be complex in the VFS details. We can defer it to Phase II if
necessary. George, you should spend a day (not this week) figuring
out how much work it would be to make that work. It will be the
details of it that will be dangerous....
OK.
