On 12/7/2010 5:43 AM, Stephen Smalley wrote: > ... > The only real question for this particular patch IMHO is whether the > changes being made here are sensible from a vfs and fs point of view. > Most of your comments seem more directed at whether or not SELinux > should be extended in this manner (i.e. the 2nd patch), and that's a > question for the SELinux developers, who have already come to > consensus on the matter. I will accept that the changes are acceptable to the SELinux community and that the proposed behavior is perceived as beneficial within that community. One of the concerns that has traditionally been raised when new LSM hooks or changes to existing hooks are proposed is that of generality. I can think of a number of ways in which the final component of a pathname could be used to make access control decisions, but I would not expect to be using them myself. Who else might you expect to make use of this LSM "enhancement", or is this something that only SELinux is ever going to want? Is the component something the LSM should be providing in general, or is this the only case in which it makes sense? I think that the LSM interfaces are awfully inconsistent and quite arbitrary, and that a little bit of consideration about the possibility of avoiding taking it even further in that direction is in order, especially when a change is in a fuzzy area that has been contentious in the past. I remember the issues that were raised when the AppArmor folks proposed LSM interface changes, and while the changes proposed today lack the problems those changes did the same issues need to be raised and addressed. In the end, I don't mind an additional parameter I'll not be using in Smack if it is generally useful. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
