On Mar 5, 2015 10:41 AM, "Christoph Lameter" <cl@xxxxxxxxx> wrote: > > On Thu, 5 Mar 2015, Serge E. Hallyn wrote: > > > > > > > > > So I'd say drop this change ^ > > > > > > Then the ambient caps get ignored for a executables that have capabilities > > > seton the file? > > > > Yes. Those are assumed to already know what they're doing. > > Do they? What if there is a LD_PRELOAD library that redirects socket calls > and that needs raw device access (there are actually a number of software > packages like that to reduce the latency of network I/O. See for example > Solarflare's software products and the current rsocket libary in OFED. > There are cap issues if the rsocket library should be made useful for > Ethernet instead of infiniband). > > > Why? Do you foresee cases where a file that has fP set needs capabilities > > that aren't in its fP? > > Yes due to the library issues. You can't LD_PRELOAD and fP together. And I'm still unconvinced that ambient caps can ever be safe in conjunction with fP. I'll grill you next week on what you're trying to do that makes you want this :) --Andy > > > It seems more likely that they'll risk misbehaving due to an unexpected set > > of caps. > > The userspace driver code in the library wont work since it does not have > the caps to access the raw device registers. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
