Arjan van de Ven wrote:
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??
Many structures exported to user space in kernel are undergoing some
change, A good application shouldn't count on invariability forever,
My test application hasn't any problem before change and after change.
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)
you can get values of these fields without any problem for kernel
thread although they are useless.
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 ;)
For this case you said, this patch has now way really, do you have a
good way to handle this case?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
