On Sun, Aug 27, 2017 at 03:31:35PM +0200, Mickaël Salaün wrote: > > > How can you add 3rd argument? All FS events would have to get it, > > but in some LSM hooks such argument will be meaningless, whereas > > in other places it will carry useful info that rule can operate on. > > Would that mean that we'll have FS_3 event type and only few LSM > > hooks will be converted to it. That works, but then we'll lose > > compatiblity with old rules written for FS event and that given hook. > > Otherwise we'd need to have fancy logic to accept old FS event > > into FS_3 LSM hook. > > If we want to add a third argument to the FS event, then it will become > accessible because its type will be different than NOT_INIT. This keep > the compatibility with old rules because this new field was then denied. > > If we want to add a new argument but only for a subset of the hooks used > by the FS event, then we need to create a new event, like FS_FCNTL. For > example, we may want to add a FS_RENAME event to be able to tie the > source file and the destination file of a rename call. that's exactly my point. To add another argument FS event to a subset of hooks will require either new FS_FOO and to be backwards compatible these hooks will call _both_ FS and FS_FOO or some magic logic on kernel side that will allow old FS rules to be attached to FS_FOO hooks? Two calls doesn't scale and if we do 'magic logic' can we do it now and avoid introducing events altogether? Like all landlock programs can be landlock type and they would need to declare what arg1, arg2, argN they expect. Then at attach time the kernel only needs to verify that hook arg types match what program requested. > Anyway, I added the subtype/ABI version as a safeguard in case of > unexpected future evolution. I don't think that abi/version field adds anything in this context. I still think it should simply be removed. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
