On Wednesday, August 05, 2015 02:30:14 AM Richard Guy Briggs wrote: > On 15/08/04, Paul Moore wrote: > > On Saturday, August 01, 2015 03:42:23 PM Richard Guy Briggs wrote: > > > Signed-off-by: Richard Guy Briggs <r...@redhat.com> > > > --- > > > > > > include/uapi/linux/audit.h | 2 ++ > > > kernel/audit.c | 2 +- > > > kernel/audit_watch.c | 8 ++++---- > > > kernel/auditsc.c | 6 +++--- > > > 4 files changed, 10 insertions(+), 8 deletions(-) > > > > Yipee, less magic numbers! > > > > However, one question for you ... are we ever going to see a device or > > inode set to -1 in the userspace facing API? In other words, should the > > new #defines go in the uapi headers or simply in kernel/audit.h? Unless > > it is part of the API, let's leave it out of uapi as we have to be very > > careful about that stuff and I'd prefer to keep it minimal. > > This is a good point. I did briefly thing about this at one point. > Perhaps Steve can answer this. It would be trivial to move it back to > uapi if needed. Would you be ok with it in include/linux/audit.h for > now?
I have no problem with it in include/linux/audit.h, that is a kernel-only include that we can change at anytime. My concern is putting it into a uapi header which makes it very hard to change. I'm thinking we should just go ahead and put it in include/linux/audit.h for now as I can't think of a reason why userspace should be passing in an invalid dev/inode value, it just doesn't make sense. If the invalid tokens prove to be valuable for userspace, we can always move the #defines. -- paul moore security @ redhat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
