[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130410173526.GF28504@madcap2.tricolour.ca>
Date: Wed, 10 Apr 2013 13:35:26 -0400
From: Richard Guy Briggs <rgb@...hat.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, Al Viro <viro@...iv.linux.org.uk>,
linux-audit@...hat.com
Subject: Re: [PATCH] [BZ905179] audit: omit check for uid and gid validity in
audit rules and data
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 <sgrubb@...hat.com> writes:
> > > On Tuesday, April 09, 2013 02:39:32 AM Eric W. Biederman wrote:
> > >> Andrew Morton <akpm@...ux-foundation.org> writes:
> > >> > On Wed, 20 Mar 2013 15:18:17 -0400 Richard Guy Briggs <rgb@...hat.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 <rbriggs@...hat.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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists