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 <rgb(a)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