RE: In-kernel process exit hooks?

["Terry Moore" <tmm%mcci.com@localhost>]

Isn't there a security risk with the fd_getfile() approach? This sounds (on
the face of it) similar to the kinds of problems that led tmpnam(3) to be
deprecated? For example, what if the monitoring program deliberately points
the fd at a file that it opened as read-only; will filemon then write to it?

--Terry

> -----Original Message-----
> From: tech-kern-owner%NetBSD.org@localhost [mailto:tech-kern-owner%NetBSD.org@localhost] On
> Behalf Of Paul Goyette
> Sent: Wednesday, January 6, 2016 16:55
> To: Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>
> Cc: tech-kern%netbsd.org@localhost
> Subject: Re: In-kernel process exit hooks?
> 
> > > Another possibility would be to change filemon(4) to do fd_getfile
> > > each it needs to use the file descriptor.  This makes it a little
> > > more brittle (fails if you close the descriptor), but would sidestep
> > > the problem.
> >
> > Hmmm, perhaps.  Failure would not be a problem, since we would just
> > revert to the initial "output file unspecified" conditions.
> >
> > I think I like this approach.  :)  I'll give it a try.
> 
> This actually works quite well.  Please see the attached diffs for your
> review.
> 
> One possible problem is what happens if the monitoring program closes
> the file descriptor, and then re-uses that fd?  I've included a check to
> compare the original 'struct file *' pointer with the current one, which
> will catch "some" instances, but not guaranteed to catch them all.  It
> could be a bit of a surprise if filemon output shows up in unexpected
> places.  :)
> 
> Because of this potential for surprising the user, I think I'm still
> leaning to my earlier proposal of extending exithook processing.  But
> given the limited number of use-cases for filemon, I could live with
> making the fd_getfile()-only-when-you-need-it change instead.
> 
> 
> +------------------+--------------------------+------------------------+
> | Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:      |
> | (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
> | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
> +------------------+--------------------------+------------------------+