On Saturday 09 June 2007 14:58, 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. /proc only uses pathnames in a few places, > > but /proc/mounts will silently fail and produce garbage entries. That's > > not ideal of course; we should fix that somehow. > > > Note that this has nothing to do with the AppArmor discussion ... > > This has everything to do with AA discussion. How pathnames are used in /proc has *nothing* to do with AppAmor. > You took unreliable, for-user-info kernel subsystem, and made security > subsystem depend on it. Oops. Wrong. I said that the kernel uses pathnames for informational purposes only, not that they are unreliable. Don't turn words around in my mouth. The dcache has a *very* precise idea of pathnames, because this is what it is there for. The pathnames that d_path computes exactly reflect what the dcache knows. (This requires the d_path fixes that are included in the AppArmor series and have also been posted independently, and the reasons why these fixes are needed are well explained in the mails.) The resulting pathnames are anything but unreliable. > > > Perhaps vfs should be modified not to allow such crazy paths? But > > > placing limit in aa is ugly. > > > > Dream on. Redefining fundamental vfs semantics is not an option; we should > > rather make sure that we fail gracefully. Considering the > > And instead of fixing "too long pathnames are problem in kernel" in any > clean way, you "simply" included > configurable-but-impossible-to-configure-right limit into > apparmor. And now you want that merged. Dream on. The choice here is between the following two things: either allow pathnames to grow to arbitrary lengths, or cap them at some point. The former has the benefit of working with all possible pathnames, and the drawback that users can consume arbitrary amounts of kernel memory by constructing arbitrarily long paths. The latter has the benefit of limiting the amount of kernel memory consumed to some upper bound, and the drawback that access to exceptionally long paths (beyond the arbitrary limit) is denied. So in a sense, the limit in AppArmor does what you are asking for: it modifies things so that the kernel does not allow "such crazy paths". It does not introduce this as a vfs limit though, because the vfs has all right not to care. Andreas - 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
