On Fri, May 15, 2009 at 08:01:45AM -0400, Stephen Smalley wrote: > > Finally, how is this safer? Don't get me wrong, I do respect > > the concern - that's why I originally went with your proposal of > > is_owner_or_cap(). But the fact is that if you've hijacked a process > > with enough privileges, you *can* make the full reflink, and if your > > hijacked process doesn't but does have read access, you *can* make the > > NOPERMS reflink. So doing it with the userspace code above is identical > > to the kernel code, except that every userspace program has to handle it > > themselves. > > As Jamie said, we aren't talking about injecting arbitrary code into the > process. The failure scenario is quite similar to the setuid() one: > arrange conditions such that the process lacks sufficient privileges to > preserve attributes, and when it calls reflink(2) expecting to preserve > the attributes, it will get no indication that they weren't preserved. > At which point the data may be unwittingly exposed beyond its original > constraints. 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? Joel -- "Same dancers in the same old shoes. You get too careful with the steps you choose. You don't care about winning but you don't want to lose After the thrill is gone." 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
