> From: David Wheeler [mailto:dwheelerat_private] > I believe fd support _does_ need to be added, in phase 1, to > reduce later > "API shuffling". > > There appears to be an understanding that there _will_ be a > phase 2 which ... > > We can't forsee all possible changes in the future, but here's a case > where the need appears to be known. Let's do it right the > first time. Exactly. The SGI folks appear to be trying to play by the "rules of the game", vague as they may be. On the one hand, they are told to not pollute phase 1 with audit and wait for phase 2, and on the other hand they are being told that phase 2 is nowhere near a certainty. So, instead of putting in the audit hooks in phase 1, they try to break up auditing into pieces that 1) change existing LSM APIs so they won't need further changing again in phase 2, and 2) break up audit functionality into smaller chunks, hoping at least one or more of them will make it into phase 1, deferring the others into phase 2. It appears they have gone through a fair amount of work to remove the objections to their initial <large> patch. After all of this, Crispin says that audit can't be included in LSM phase 1 at all and have LSM accepted into the kernel. Is this still the case? Will any amount of audit functionality in phase 1 be acceptable? If not, why is there -any- phase 1 audit work being done? Why call for SGI to split the patch into smaller patches and lead them on? Does anyone know the chances of a phase 2? If it is small, that is, if the kernel developers are giving us 1 window of opportunity and then closing the door, pre-phase 2 work should not be added to phase 1. If on the other hand, phase 2 is very probable if phase 1 is accepted, it makes sense to put the fd hooks in now to avoid API disruption. Perhaps if we got consensus in this group on phase 1 LSM scope, and the odds of a phase 2, we could proceed with a clearer view by all as to which patches are true candidates for phase 1. I see no such consensus at this time, which is why we have this circular discussion. --steve kramer _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Wed Jul 25 2001 - 07:01:27 PDT