On Thu, 04.06.15 13:24, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> On Wed, Jun 03, 2015 at 11:23:51AM -0400, Mimi Zohar wrote: > > On Wed, 2015-06-03 at 06:50 +0200, Lennart Poettering wrote: > > > On Tue, 02.06.15 11:55, Mimi Zohar (zo...@linux.vnet.ibm.com) wrote: > > > > > > > > We could add another parameter to copy_bytes(), but in this case it's > > > > > cleaner to call fstat() and loop_write(). > > > > > > > > Right. copy_bytes has no concept of rules/records. So either "another > > > > parameter" is added to copy_bytes to indicate skip try_sendfile and > > > > write the entire policy, or [partially] revert the patch to calll > > > > loop_write() to write the entire policy directly. > > > > > > In which way does sendfile() fail here? I mean, the code currently > > > understands ENOSYS and EINVAL as indications that sendfile() is not > > > supported on an fd. What does sendfile() on the IMA device return? > > > Most likely we can just check for that error code, and then try the > > > loop as fallback. > > > > After the sendfile failure, in addition to resetting the file position > > to the beginning of the file, the file would also need to be closed and > > re-opened. Otherwise, IMA assumes the policy was malformed and fails > > the policy update. > OK, this seems just now worth the complication. I pushed this patch as is. I'd really prefer if we'd understand the issue first, before we push patches about things. Can you explain why the file position would have been altered by sendfile()? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
