10 a.m.
--- Stephen Smalley <sds(a)tycho.nsa.gov> wrote:
> That would require two copyins, one to get the
> lengths and another to get the "buf". Not that
> that's necessarily a stopper, but I had assumed
> the goal was a one-shot interface.
No, the whole thing is sent as a single buffer that
is copied into the
kernel once.
But you don't know how much to copy. If you
decide on a fixed amount you may as well use
the previously discussed structure.
buf[0] at the end of a structure is
common practice to
reference data stuffed directly at the end of the
structure.
Yup, and I'd have suggested it myself save for
the two copy problem.
Casey Schaufler
casey(a)schaufler-ca.com
__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
10:01 a.m.
New subject: watch structure
On Tue, 2005-04-05 at 08:00 -0700, Casey Schaufler wrote:
But you don't know how much to copy. If you
decide on a fixed amount you may as well use
the previously discussed structure.
I think that this is just a communication problem between you and me;
the program knows the total length of the buffer, and passes it to the
sendto() call when sending the buffer to the netlink socket. The kernel
can then copy the entire buffer in once, and subsequently can extract
the strings using the length information in the header of the buffer.
Only one copyin required.
--
Stephen Smalley <sds(a)tycho.nsa.gov>
National Security Agency
10:10 a.m.
New subject: watch structure
On Tuesday 05 April 2005 11:00, Casey Schaufler wrote:
But you don't know how much to copy.
Sure you do. The lengths are in 2 other fields of the same structure. When
using this scheme, you have to verify the length of the netlink packet meshes
with the lengths provided or reject it. This technique does increase the
amount of checking before using the data.
-Steve
10:13 a.m.
New subject: watch structure
On Tue, 2005-04-05 at 11:10 -0400, Steve Grubb wrote:
On Tuesday 05 April 2005 11:00, Casey Schaufler wrote:
> But you don't know how much to copy.
Sure you do. The lengths are in 2 other fields of the same structure. When
using this scheme, you have to verify the length of the netlink packet meshes
with the lengths provided or reject it. This technique does increase the
amount of checking before using the data.
Shrug. In any event, this is not a performance-critical path, right?
So it doesn't really matter either way, as long as the kernel internal
representation of watches (not necessarily the same as the kernel-
userspace interface) is memory efficient.
Question: Would it be sane for Tim to go ahead and re-base his patch to
the latest -mm and submit his RFC on linux-fsdevel now even before
resolving the userspace interface issue? Or do we need to get the
userspace interface finalized first?
--
Stephen Smalley <sds(a)tycho.nsa.gov>
National Security Agency
10:35 a.m.
New subject: watch structure
On Tuesday 05 April 2005 11:13, Stephen Smalley wrote:
In any event, this is not a performance-critical path, right?
Right. I'm just mentioning it now in hopes that Tim adds the additional sanity
checks before trusting the lengths sent into the kernel.
Question: Would it be sane for Tim to go ahead and re-base his patch
to
the latest -mm and submit his RFC on linux-fsdevel now even before
resolving the userspace interface issue?
I would tentatively say yes. It may take a few days to finalize the list
watches. (Changing this structure the first step.) Hopefully, dumping the
whole list without a path doesn't change the underlying design in any
significant way. If dumping the whole list will change the design, we may
need to hold off depending on what the changes involve.
-Steve
10:32 a.m.
New subject: watch structure
On Tue, 2005-04-05 at 11:35 -0400, Steve Grubb wrote:
> Question: Would it be sane for Tim to go ahead and re-base his
patch to
> the latest -mm and submit his RFC on linux-fsdevel now even before
> resolving the userspace interface issue?
I would tentatively say yes. It may take a few days to finalize the list
watches. (Changing this structure the first step.) Hopefully, dumping the
whole list without a path doesn't change the underlying design in any
significant way. If dumping the whole list will change the design, we may
need to hold off depending on what the changes involve.
Even if it requires significant internal changes to auditfs, I don't
think it will have any impact on the hooks in the VFS, which is
primarily what we need to get feedback on from linux-fsdevel.
--
Stephen Smalley <sds(a)tycho.nsa.gov>
National Security Agency
12:49 p.m.
New subject: watch structure
On Tuesday 05 April 2005 10:32 am, Stephen Smalley wrote:
On Tue, 2005-04-05 at 11:35 -0400, Steve Grubb wrote:
> > Question: Would it be sane for Tim to go ahead and re-base his patch
> > to the latest -mm and submit his RFC on linux-fsdevel now even before
> > resolving the userspace interface issue?
>
> I would tentatively say yes. It may take a few days to finalize the list
> watches. (Changing this structure the first step.) Hopefully, dumping the
> whole list without a path doesn't change the underlying design in any
> significant way. If dumping the whole list will change the design, we may
> need to hold off depending on what the changes involve.
Even if it requires significant internal changes to auditfs, I don't
think it will have any impact on the hooks in the VFS, which is
primarily what we need to get feedback on from linux-fsdevel.
Perhaps I should write out a TODO list on the e-mail to fsdevel to minimize
diversion?
--
-tim
12:43 p.m.
New subject: watch structure
On Tue, 2005-04-05 at 12:49 -0500, Timothy R. Chavez wrote:
Perhaps I should write out a TODO list on the e-mail to fsdevel to
minimize
diversion?
I don't think it matters, unless there is a todo item that is expected
to affect the VFS hooks.
--
Stephen Smalley <sds(a)tycho.nsa.gov>
National Security Agency
7200
days inactive
7200
days old
linux-audit@lists.linux-audit.osci.io
7 comments
4 participants
participants (4)
-
Casey Schaufler -
Stephen Smalley -
Steve Grubb -
Timothy R. Chavez