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@xxxxxxxxxx> 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
