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