From: Andreas Gruenbacher <agruen@suse.de>
Organization: SUSE Labs, Novell
To: Pavel Machek <pavel@ucw.cz>
Subject: Re: [AppArmor 38/45] AppArmor: Module and LSM hooks
Date: Mon, 4 Jun 2007 16:30:49 +0200
User-Agent: KMail/1.9.5
Cc: jjohansen@suse.de, linux-kernel@vger.kernel.org,
       linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org
References: <20070514110607.549397248@suse.de> <200706041342.42178.agruen@suse.de> <20070604131242.GE1971@elf.ucw.cz>
In-Reply-To: <20070604131242.GE1971@elf.ucw.cz>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200706041630.49316.agruen@suse.de>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1147
Lines: 26

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. /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 ...

> 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 alternatives, I 
still prefer the configurable limit. That's way more useful than allowing a 
process to DOS the kernel with AppArmor.

Andreas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/