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 Fri, Jun 22, 2007 at 10:23:03AM -0400, James Morris wrote: > On Fri, 22 Jun 2007, Chris Mason wrote: > > > But, this is a completely different discussion than if AA is > > solving problems in the wild for its intended audience, or if the code > > is somehow flawed and breaking other parts of the kernel. > > Is its intended audience aware of its limitiations? Lars has just > acknowledged that it does not implement mandatory access control, for one. > > Until people understand these issues, they certainly need to be addressed > in the context of upstream merge. It is definitely useful to clearly understand the intended AA use cases during the merge. > > > We've been over the "AA is different" discussion in threads about a > > billion times, and at the last kernel summit. > > I don't believe that people at the summit were adequately informed on the > issue, and from several accounts I've heard, Stephen Smalley was > effectively cut off before he could even get to his second slide. I'm sure people there will have a different versions of events. The one part that was discussed was if pathname based security was useful, and a number of the people in the room (outside of novell) said it was. Now, it could be that nobody wanted to argue anymore, since most opinions had come out on one list or another by then. But as someone who doesn't use either SElinux or AA, I really hope we can get past the part of the debate where: while(1) AA) we think we're making users happy with pathname security SELINUX) pathname security sucks So, yes Greg got it started and Lars is a well known trouble maker, and I completely understand if you want to say no thank you to an selinux based AA ;) The models are different and it shouldn't be a requirement that they try to use the same underlying mechanisms. -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 Fri, Jun 22, 2007 at 09:48:12AM -0400, James Morris wrote: > On Fri, 22 Jun 2007, Chris Mason wrote: > > > > 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. > > There are two distinct concepts here. > > A. Pathname labeling - applying access control to pathnames to objects, > rather than labeling the objects themselves. > > Think of this as, say, securing your house by putting a gate in the street > in front of the house, regardless of how many other possible paths there > are to the house via other streets, adjoining properties etc. > > Pathname labeling and mediation is simply mediating a well-known path to > the object. In this analogy, object labeling would instead ensure that > all of the accessible doors, windows and other entrances of the house were > locked, so that someone trying to break in from the rear alley would > not get in simply by bypassing the front gate and opening any door. > > What you do with AppArmor, instead of addressing the problem, is just > redefine the environment along the lines of "set your house into a rock > wall so there is only one path to it". > > > B. Pathname access control as a general abstraction for OS security. > > Which is what was being discussed above, in response to a question from > Lars about technical issues, and that this _model_ doesn't generalize to > the rest of the OS, regardless of whether you think the mechanism of > pathname labeling itself is appropriate or not. I'm sorry, but I don't see where in the paragraphs above you aren't making a general argument against the pathname model. I'm not trying to get into that discussion (I'm smart enough to know I'm far too stupid to hold my own there). I do understand that AA is different from selinux, and that you have valid points about the level and type of protection that AA offers. But, this is a completely different discussion than if AA is solving problems in the wild for its intended audience, or if the code is somehow flawed and breaking other parts of the kernel. We've been over the "AA is different" discussion in threads about a billion times, and at the last kernel summit. I think Lars and others have done a pretty good job of describing the problems they are trying to solve, can we please move on to discussing technical issues around that? -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
