mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@infradead.org>
To: Yi Yang <yang.y.yi@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>, Andrew Morton <akpm@osdl.org>
Subject: Re: [2.6.16-rc5-m3 PATCH] inotify: add the monitor for the event source
Date: Thu, 09 Mar 2006 06:35:13 +0100	[thread overview]
Message-ID: <1141882513.2883.2.camel@laptopd505.fenrus.org> (raw)
In-Reply-To: <440FBA9C.3050109@gmail.com>

On Thu, 2006-03-09 at 13:18 +0800, Yi Yang wrote:
> Arjan van de Ven wrote:
> > On Thu, 2006-03-09 at 00:33 +0800, Yi Yang wrote:
> >   
> >> Current inotify implementation only focus on change of file system, but it doesn't
> >>  know who results in this change, this patch adds three fields to struct inotify_event,
> >>  tgid, uid and gid, they will save process ID, user ID and user group ID of the process
> >>  which leads to change in the file system, such software as anti-virus can make use 
> >> of this feature to monitor who is modifying a specific file.
> >>     
> >
> >
> > this patch appears to change the ABI! That is bad bad bad.
> >   
> a change of struct inotify_event can't change ABI, can you describe it 
> more clear?

it breaks ABI because this structure is communicated to userspace, and
you change both the layout and the size of it. What else would ABI
mean??


> > Also, how can you guarantee that "current" is valid and meaningful at
> > the place you use it to get the user id ??
> >   
> Of course, current process/thread never disappears before fsnotify_* 
> returns.

but... what makes you think it's not a kernel thread such as kjournald?
(which have basically meaningless current)


> > Also the process ID part is really bogus, after all the process may have
> > exited by the time the inotify client gets to it, and the PID may even
> > already have been reused.
> >
> >   
> Your concern is correct, but uid and git can give out some hints, I ever 
> considered to
> save the name of current process, however that needs a bigger and 
> length-variable
> inotify_event struct, moreover, to get the full path name of current 
> process/thread
> in kernel will have a big overhead, so I must select a comprise way.

there is no "full path name" concept in linux like that. And even worse,
many processes will not have *any* path because they have been deleted,
especially the viruses will use this ;)



  reply	other threads:[~2006-03-09  5:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-08 16:33 Yi Yang
2006-03-08 16:53 ` Arjan van de Ven
2006-03-09  5:18   ` Yi Yang
2006-03-09  5:35     ` Arjan van de Ven [this message]
2006-03-09  9:55       ` Yi Yang
2006-03-09 19:35         ` Arjan van de Ven
2006-03-10  1:27           ` Yi Yang
2006-03-10  7:39             ` Arjan van de Ven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1141882513.2883.2.camel@laptopd505.fenrus.org \
    --to=arjan@infradead.org \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yang.y.yi@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®