Re: [PATCH 00/37] Permit filesystem local caching
On Thursday 21 February 2008, David Howells wrote: David Howells [EMAIL PROTECTED] wrote: Have you got before/after benchmark results? See attached. Attached here are results using BTRFS (patched so that it'll work at all) rather than Ext3 on the client on the partition backing the cache. Thanks for trying this, of course I'll ask you to try again with the latest v0.13 code, it has a number of optimizations especially for CPU usage. Note that I didn't bother redoing the tests that didn't involve a cache as the choice of filesystem backing the cache should have no bearing on the result. Generally, completely cold caches shouldn't show much variation as all the writing can be done completely asynchronously, provided the client doesn't fill its RAM. The interesting case is where the disk cache is warm, but the pagecache is cold (ie: just after a reboot after filling the caches). Here, for the two big files case, BTRFS appears quite a bit better than Ext3, showing a 21% reduction in time for the smaller case and a 13% reduction for the larger case. I'm afraid I don't have a good handle on the filesystem operations that result from this workload. Are we reading from the FS to fill the NFS page cache? For the many small/medium files case, BTRFS performed significantly better (15% reduction in time) in the case where the caches were completely cold. I'm not sure why, though - perhaps because it doesn't execute a write_begin() stage during the write_one_page() call and thus doesn't go allocating disk blocks to back the data, but instead allocates them later. If your write_one_page call does parts of btrfs_file_write, you'll get delayed allocation for anything bigger than 8k by default. = 8k will get packed into the btree leaves. More surprising is that BTRFS performed significantly worse (15% increase in time) in the case where the cache on disk was fully populated and then the machine had been rebooted to clear the pagecaches. Which FS operations are included here? Finding all the files or just an unmount? Btrfs defrags metadata in the background, and unmount has to wait for that defrag to finish. Thanks again, Chris - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Thu, Jun 21, 2007 at 09:06:40PM -0400, James Morris wrote: On Thu, 21 Jun 2007, Chris Mason wrote: The incomplete mediation flows from the design, since the pathname-based mediation doesn't generalize to cover all objects unlike label- or attribute-based mediation. And the use the natural abstraction for each object type approach likewise doesn't yield any general model or anything that you can analyze systematically for data flow. This feels quite a lot like a repeat of the discussion at the kernel summit. There are valid uses for path based security, and if they don't fit your needs, please don't use them. But, path based semantics alone are not a valid reason to shut out AA. The validity or otherwise of pathname access control is not being discussed here. The point is that the pathname model does not generalize, and that AppArmor's inability to provide adequate coverage of the system is a design issue arising from this. I'm sorry, but I don't see where in the paragraphs above you aren't making a general argument against the pathname model. -chris - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote: On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote: On 2007-06-21T15:42:28, James Morris [EMAIL PROTECTED] wrote: A veto is not a technical argument. All technical arguments (except for path name is ugly, yuk yuk!) have been addressed, have they not? AppArmor doesn't actually provide confinement, because it only operates on filesystem objects. What you define in AppArmor policy does _not_ reflect the actual confinement properties of the policy. Applications can simply use other mechanisms to access objects, and the policy is effectively meaningless. Only if they have access to another process which provides them with that data. Or can access the data under a different path to which their profile does give them access, whether in its final destination or in some temporary file processed along the way. And now, yes, I know AA doesn't mediate IPC or networking (yet), but that's a missing feature, not broken by design. The incomplete mediation flows from the design, since the pathname-based mediation doesn't generalize to cover all objects unlike label- or attribute-based mediation. And the use the natural abstraction for each object type approach likewise doesn't yield any general model or anything that you can analyze systematically for data flow. This feels quite a lot like a repeat of the discussion at the kernel summit. There are valid uses for path based security, and if they don't fit your needs, please don't use them. But, path based semantics alone are not a valid reason to shut out AA. -chris - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
