Hi! > > > > 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 Well, we know they are unreliable from other sources. > 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. Yes? Like... everything but AA works with very long paths? Like... deleted files handling, where AA used to pick random name? Like... races during tree renames, where AA may use name file never ever had? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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
