On Mon, 2007-06-04 at 16:30 +0200, Andreas Gruenbacher wrote: > On Monday 04 June 2007 15:12, Pavel Machek wrote: > > How will kernel work with very long paths? I'd suspect some problems, > > if path is 1MB long and I attempt to print it in /proc > > somewhere. > > Pathnames are only used for informational purposes in the kernel, except in > AppArmor of course. I don't mean this as a flame, but isn't the above statement the very crux of this discussion? Why should AppArmor be different from the rest of the kernel in its usage of pathnames (basis for decisions vs. informational reporting to userspace)? And if it is ok for AppArmor to generate and use pathnames as its basis of decisions on each open, then is it also ok for audit, inotify, and others to use them in the same manner? If the audit developers or inotify developers had come with patches that used d_path or equivalent in the same manner as AppArmor, don't you think they would have gotten the same resistance? And if you are truly trying to create a mechanism (in AppArmor) that you can ultimately apply widely to the system (going beyond AppArmor's original limited focus on a small set of network-facing daemons), aren't you concerned about the implications of having to generate a pathname on each open just to decide what to do? Is this really the "path" you want to take ;)? Another question: it seems like the read-only bind mount folks gave up on propagating the vfsmounts down and switched to a rather different approach (checking near the entry points, using mount writer counters). So similarly, what makes AppArmor fundamentally different that it wouldn't take a similar approach to what they are doing vs. propagating the vfsmounts down? Or do you think they made the wrong choice? If so, why? Just trying to understand your position better... -- Stephen Smalley National Security Agency - 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
