The ports move
Robert Watson
rwatson at FreeBSD.org
Sat Jul 16 10:53:37 GMT 2005
On Fri, 15 Jul 2005, Samy Al Bahra wrote:
> We will soon be making an inevitable move with MAC by moving the
> TrustedBSD/FreeBSD policies out of the main tree and into the ports
> system. To the people who prefer certain modules to be in base, a simple
> distribution set can be made for repeated installs. This is done in
> hopes to recognize and support 3rd-party policies in a scalable manner.
>
> Ports will be created for:
<snip>
> mac_lomac
</snip>
I think it would make sense to only move things to ports where they have
clear maintainers/owners, or we risk increasing the risk of rottage.
Your list seems pretty reasonable, but I would omit mac_lomac from it. If
there are other policies on the list that don't have clear owners, we
should identify them before moving them.
> While, mac_none, mac_stub, mac_test, mac_mls and mac_biba will remain in
> base. A patch will be sent for inclusion in the ports system to the
> ports team to recognize a proposed API tracking scheme for MAC.
The proper order here is probably:
- Get things working as ports, shake out the inevitable nits. There's an
existing practice of having ports for things already in the base system,
so that should meet your magic threshold number.
- Simultaenous to that, work out API/ABI issue. See below.
- Make sure everything is still working.
- Remove the duplicate policies from the HEAD branch, but not earlier
branches.
> A security.mac.version will be added containing a string value similar
> to _FreeBSD_version for 3rd party policies to make use of. The scheme we
> will be making use of will use a linear system for -HEAD. For example,
> -HEAD will have the special prefix of "99". With every API change in
> -HEAD we will increment our counter. So, the version will be "9900000"
> at time of import into our tree. If we were to make an API change, we
> would bump the -HEAD counter to "9900001". Upon branching for a release,
> a new prefix would be created for that branch. For example, at one
> point, -HEAD might be at "9900123", if we were to branch it for a 7.X
> release, 7.X will have a _MAC_version/security.mac.version of "700000"
> (note the implicit zero BTW). API changes would be tracked across
> branches elegantly in this manner. If no feedback is provided in the
> coming days, we will assume everyone is fine with the above, and the
> move will occur with the above plans. The above will pertain to future
> policy maintainers in the coming MAC virtual category in ports.
My current leaning on API/ABI is:
(1) We do not break existing ABIs once on a branch -- specifically, no
module compiled for a branch will fail to work in a forward compatible
way along the branch.
(2) We can add features, identified by the mac version feature counter for
the branch, one bump per feature, as long as it doesn't violate (1)
(3) The MAC Framework linker version will be incremented for each branch
-- i.e., '1' for 5.x, '2' for 6.x, and '3' for 7.x. This isn't quite
in place but will be fixed in a few days when I finish a spate of
merges to 6.x.
(4) No ABI/API guarantees are made prior to cutting of the first -STABLE
release on a branch. For 5.x, this was 5.3, but for 6.x, it will be
6.0.
Obviously, "fail to work" is something subject to interpretation. The
obvious practical implications, though, are:
- Structures shared between policy modules and the MAC Framework cannot
change size if the size is part of the defined ABI.
- The prototypes of functions can be changed, but only in terms of adding
arguments, not removing or substantially cnging them.
- Structures/interfaces that aren't part of the MAC Framework API/ABI are
subject to whatever constraints they normally have for API/ABI. If you
consume a non-MAC API/ABI in a policy, you are subject to its
properties. For example, many policies perform extended attribute VOP's
to back labels, and therefore are subject to changes in the VFS API/ABI
in the kernel.
The most practical import is that we should make sure that if we plan to
add specific entry points over the lifetime of a branch, that we have
place-holder pointers in struct mac_policy_ops.
Robert N M Watson
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message
More information about the trustedbsd-discuss
mailing list