On Fri, May 15, 2009 at 11:55:25AM -0400, Stephen Smalley wrote: > > I wasn't being specific to injected code. Assume we have a > > deliberate flag to reflinkat(2). Then we provide reflink(3) in > > userspace that does the fallback, keeping it out of the kernel. Doesn't > > that have the exact same problem? > > You wouldn't always do the fallback in reflink(3), but instead provide a > helper interface that would perform the fallback for applications that > want that behavior. But isn't that reflink(3)? And the application that wants to know uses reflinkat(2)? > > Consider a program that wants to always preserve attributes on the > reflinks it creates. If the interface allows the program to explicitly > request that behavior and returns an error when the request cannot be > honored, then the program knows that upon a successful return, the > attributes were in fact preserved. If the interface instead silently > selects a behavior based on the current privileges of the process and > gives no indication to the caller as to what behavior was selected, then > the opportunity for error is great. I get that. I'm looking at what the programming interface is. What's the standard function for "I want the fallback behavior" called? What's the standard function for "I want preserve security" called? "int reflink(oldpath, newpath)" has to pick one of the behaviors. Which is it? Joel -- Life's Little Instruction Book #69 "Whistle" Joel Becker Principal Software Developer Oracle E-mail: joel.becker@xxxxxxxxxx Phone: (650) 506-8127 -- 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
