On 06/17/2014 12:01 PM, David Herrmann wrote:
I don't think this is what potential users expect because mlock requires
capabilities which are not available to them.
A couple of weeks ago, sealing was to be applied to anonymous shared memory.
Has this changed? Why should *reading* it trigger OOM?
The file might have holes, therefore, you'd have to allocate backing
pages. This might hit a soft-limit and fail. To avoid this, use
fallocate() to allocate pages prior to mmap()
This does not work because the consuming side does not know how the
descriptor was set up if sealing does not imply that.
or mlock() to make the kernel lock them in memory.
See above for why that does not work.
I think you should eliminate the holes on sealing and report ENOMEM
there if necessary.
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
