On Wed, Apr 10, 2013 at 12:20:18PM -0400, Richard Guy Briggs wrote: > On Tue, Apr 09, 2013 at 02:16:22PM -0700, Eric W. Biederman wrote: > > Steve Grubb <sgr...@redhat.com> writes: > > > On Tuesday, April 09, 2013 02:39:32 AM Eric W. Biederman wrote: > > >> Andrew Morton <a...@linux-foundation.org> writes: > > >> > On Wed, 20 Mar 2013 15:18:17 -0400 Richard Guy Briggs > > >> > <r...@redhat.com> wrote: > > >> >> audit rule additions containing "-F auid!=4294967295" were failing > > >> >> with > > >> >> EINVAL. > > >> >> > > >> >> UID_INVALID (and GID_INVALID) is actually a valid uid (gid) for > > >> >> setting > > >> >> and > > >> >> testing against audit rules. Remove the check for invalid uid and gid > > >> >> when > > >> >> parsing rules and data for logging. > > >> > > >> In general testing against invalid uid appears completely bogus, and > > >> should always return true. As it is and essentially always has been > > >> incorrect to explicitly set any kernel uid to that value. > > > > > > This is the unset value that daemons would have. > > > > As their uid, or gid, or euid, or fsuid. Not in the least. > > Point taken that only a value of UID_INVALID should be accepted for > auid.
> > And no one has much cared > > about the audit subsystem this "breakage" of the audit > > subsystem. Despite things failing with a clear error code. So there are > > two choices. We mark the audit subsystem as broken moving it to staging > > and then delete it because no one cares enough to look after it and > > maintain it. Or we have a constructive conversation about what to do > > with it. > > Ok, politics aside... > > > I have proposed a patch that will preserve the existing behavior while > > adding maintainable semantics. Will someone who cares please test my > > proposed fix? > > I'll test it. Meanwhile, could you please respond to my other comments interlaced in my previous reply earlier in the thread? In particular the question about f->val == 1. > > Eric > > - RGB - RGB -- Richard Guy Briggs <rbri...@redhat.com> Senior Software Engineer AMER ENG Base Operating Systems Remote, Canada, Ottawa Voice: 1.647.777.2635 Internal: (81) 32635 -- 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/
