hello, anybody there?

[Robert Watson]

On Mon, 5 Feb 2001, Ilmar S. Habibulin wrote:

> > Andrew Reiter has been working on the auditing subsystem design, and
> > hopefully will have the opportunity to post something about that work in
> > the near future :-).
> 
> Robert, can we have some common patch, which will include all subsystems?

Yes, this is a continuing problem, partially because of the nature of CVS.
CVS makes it difficult to have a hierarchal development model where you
have a central source repository you want to track, a local repository
with version and merging history, and local code trees.  It only really
supports a single central repository, making a more complex model
difficult.  So far, I've been using two different approaches:

1) Maintain a local repository during development of a feature, then when
it's time to merge the feature into the central reposistory, port the
feature forwards.  This works fine as long as the feature being developed
doesn't get too mixed up in rapidly moving components of the central
repository.  For example, once APIs are fairly well defined, and assuming
things like locking models don't change, code chunks such as ACLs can be
developed well in this model, allowing for local version history.

2) Use the central repository, regularly merging, but not retaining
automated local version history (instead rely on a series of patches that
change fairly heavily over time, due to rapidly moving central
repository).  Because of the degree of motion in the central FreeBSD
repository, I've been taking this approach with both Capabilities and MAC. 
This makes it harder to work collaboratively, and also makes it hard to
track changes in the MAC code, rather than the central code.

The other problem you've raised is whether or not to merge the development
trees for the various features.  In many ways, this would make sense: 
although ACLs and Capabilities can, to a large extent, remain independent,
features such as POSIX.1e-style MAC depent on the availability of
Capabilities to provide upgrade and downgrade privilege.  One of the
reasons I focussed on extended attributes early was so that it, as a
dependency for almost all other features, would be available to all of
them in a consistent form.  One of the issues that it is desirable to
maintain seperate trees is the schedule for merging features back into the
base system: my approximate order for committing the changes is:

 - ACL interfaces, EA Interfaces (done)
 - EA implementation (done)
 - Capability interface (done)
 - ACL implementation (this is next)
 - Capability implementation
 - MAC interface
 - Audit interface
 - MAC implementation
 - Audit implementation

Combining the trees would make this sort of merge difficult; the way I'm
currently addressing getting both Capabilities and ACLs working at the
same time has been to include a small amount of #ifdef'd code in my
kern_acl.c in the ACL distribution, which is where most of the overlap is
between the two in terms of changes (in the ACL version of vaccess()). 
This model breaks down for MAC, as I've described, as both it and
Capabilities touch a lot of code, and almost always the same code (the
access control hooks all over the tree.  One of my long-term goals is to
develop an improved architecture for access control in FreeBSD, so that
rather than touching the tree all over the place for a new access control
feature, you can modify reasonable abstractions.  This would allow
features such as MAC to be largely pluggable.  However, this is a
long-term goal; for the time being I've been settling with smaller
improvements in abstractions (such as moving towards a single interface
for inter-process access control rather than slightly different checks all
over the kernel, adding the VADMIN checks to replace uid checks where
possible in UFS, and so on).  I need to make some similar types of changes
in the network subsystem as we work on MAC; these improved abstractions
(after reasonable testing) are going into the base FreeBSD tree, meaning
that all of the features can depend on them. 

I've considered moving to other version control systems, but there is a
lot to be said for using what you know (CVS), even if it does impose some
impediments.  I'll continue to keep this in mind as we move forward,
needless to say, especially as features such as MAC evolve, and especially
as the dependencies between features increase.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert at fledge.watson.org      NAI Labs, Safeport Network Services



To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message