Re: watching a file for ownership change

From: Joe McGuckin (joe_at_via.net)
Date: 05/24/05

  • Next message: Dan Nelson: "Re: Forcing static-linking on a port?" 
    Date: Mon, 23 May 2005 20:54:00 -0700
To: Marco Molteni <molter@tin.it>, <hackers@freebsd.org>

    It seems like you'd want your kevent() callback (or whatever) to be
    triggered as the modifying process is exiting the syscall that is modifying
    the file but before control is actually passed back to it - you'd want to be
    able to 'catch it in the act' so to speak.

    On 5/23/05 1:23 PM, "Marco Molteni" <molter@tin.it> wrote:

    > On Sun, 22 May 2005 04:05:50 +0100
    > Bruce M Simpson <bms@spc.org> wrote:
    >
    >> On Sat, May 21, 2005 at 10:38:30PM -0400, Charles Sprickman wrote:
    >>> I'd like to find a way to watch one of the user's maildirsize files
    >>> that seems to flip ownerships at least once a day and try to
    >>> determine what process is changing the ownership.
    >>> How can I do that without dropping a bunch of daemons on a
    >>> production machine into heavy-debug mode? OS is 4.8 with all
    >>> current patches.
    >>
    >> You could try watching kevent() on the file for EVFILT_VNODE with
    >> NOTE_ATTRIB. You'd need to write a small C program to do this.
    >>
    >> Whilst this won't tell you who did what, it could give you
    >> sufficiently good timestamps from it happening to begin tracking the
    >> culprit down further, perhaps using lsof.
    >
    > When I saw the first post I actually wrote the kevent program
    > you are sugesting as an exercise, then I realized that I couldn't
    > obtain the PID of the process that modified the file.
    >
    > Would it be feasible/reasonable to add this feature to kqueue ?
    >
    > marco
    > _______________________________________________
    > freebsd-hackers@freebsd.org mailing list
    > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" 

    -- 
Joe McGuckin
ViaNet Communications
994 San Antonio Road
Palo Alto, CA  94303
Phone: 650-213-1302
Cell:  650-207-0372
Fax:   650-969-2124
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
  • Next message: Dan Nelson: "Re: Forcing static-linking on a port?"

    Relevant Pages

    • Re: [take6 1/3] kevent: Core files.
      ... it is never touched by kernel. ... kevent should not be used or kevent_enqueuewill fail to add ... of calling syscall, so syscall just becomes "wait until there is a ... it is hard to map standard errnos onto new and complex non-standard ...
      (Linux-Kernel)
    • Re: [take24 0/6] kevent: Generic event handling mechanism.
      ... for the latest stable lighttpd version and test it with kevent. ... This is as far as the kernel is concerned. ... How should it know which syscall should be interrupted when special syscall ... keep the interface as small as possible. ...
      (Linux-Kernel)
    • Re: [RFC 1/4] kevent: core files.
      ... Except that kevent has completely different structures and it is ... Magic pointer returned from aio syscall is no pollable too. ... some source constantly spewing into the ring:/. ... If I understand you correct you are talking about level triggering ...
      (Linux-Kernel)
    • Re: [take24 0/6] kevent: Generic event handling mechanism.
      ... When you will tell me why you want syscall ... But the event handling is not about AIO alone. ... almost the same happens when signal is delivered using kevent (special ... since signals are not delivered in the old way, ...
      (Linux-Kernel)
    • [take25 0/6] kevent: Generic event handling mechanism.
      ... Kevent is a generic subsytem which allows to handle event notifications. ... Events are provided into kernel through control syscall and can be read ... Changes from 'take24' patchset: ...
      (Linux-Kernel)