Commit 13c164b1a186 - regression for LSMs/SELinux?
Ian Kent
raven at themaw.net
Wed Sep 30 10:39:37 UTC 2020
On Wed, 2020-09-30 at 13:50 +0800, Ian Kent wrote:
> On Tue, 2020-09-29 at 20:00 +0200, Christoph Hellwig wrote:
> > On Tue, Sep 29, 2020 at 10:23:50AM -0700, Linus Torvalds wrote:
> > > On Tue, Sep 29, 2020 at 5:16 AM Ondrej Mosnacek <
> > > omosnace at redhat.com> wrote:
> > > > OK, so it seems that reverting comes out as the best choice
> > > > here.
> > >
> > > Yeah.
> > >
> > > > BTW, I'm looking at rw_verify_area() and I see this "If (ppos)"
> > > > check
> > > > and the comment above it... And then I look at autofs_write(),
> > > > which
> > > > passes &file->f_pos, while ksys_write() passes file_ppos(file)
> > >
> > > Ok, that doesn't matter for the security_file_permission() issue,
> > > but
> > > yes, autofs is doing the traditional thing, and it's pointless.
> > > Using
> > > file_ppos(file) isn't an option since it's an inline to
> > > read_write.c,
> > > but it could just pass in NULL these days and avoid that too.
> > >
> > > So how about we just do the appended patch? Can whoever sees this
> > > problem just verify, even though it looks trivially correct...
> >
> > This looks sensible to me. I'd throw in a
> >
> > /* only for autofs, don't use in new code */
> >
> > near the export, but users of these kind of functions tend to be
> > blind copy and paste code anyway, so the comment probably isn't
> > even read by the relevant parties..
>
> I'll build a patched kernel and give it a whirl.
Duplicated the problem first then built a patched kernel and tested.
The patch makes the problem go away, communication to the daemon
is occurring fine so the use of NULL as the file position is ok.
It looks like the error returns should be as before which is good
but there may be another problem I need to fix in there that became
apparent because this problem drew attention to it. That's something
else entirely though.
>
> Ian
More information about the Linux-security-module-archive
mailing list