Subject: Re: kern/35278: veriexec sometimes feeds user va to log(9)
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: netbsd-bugs
Date: 12/20/2006 10:05:03
The following reply was made to PR kern/35278; it has been noted by GNATS.

From: yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi)
To: elad@NetBSD.org
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/35278: veriexec sometimes feeds user va to log(9)
Date: Wed, 20 Dec 2006 19:03:02 +0900 (JST)

 > >> wouldn't that mean changes to either namei() api and/or struct nameidata
 > >> abi?
 > 
 > > yes.
 > 
 > then I'd propose to add this to struct nameidata:
 > 
 > 	char *ni_pathname;
 > 
 > and this to NDINIT():
 > 
 > 	(ndp)->ni_pathname = NULL;
 > 
 > and namei() to store the pathname in 'ni_pathname' if it's not NULL. so
 > callers that want the path can just:
 > 
 > 	nd.ni_pathname = PNBUF_GET();
 > 
 > and later free it. there's probably a better way to do this (without
 > risking memory leaks) but I'm not familiar with namei() internals.
 
 i'm not a fan of adding more functionalities to namei().
 it's better to simplify namei() instead.
 i'd suggest something like this.
 
 sys_xxx()
 {
 	pathname_t *pn;
 
 	error = pathname_get(user_pointer, &pn); /* allocate buffer and copyinstr */
 	NDINIT(.., pn, ..);
 
 	pathname_put(pn);
 }
 
 > for the meantime, I think we should use the patch I posted, at least for
 > 4.0, until we decide how to handle this otherwise.
 
 how about just disabling pathname logging?
 
 YAMAMOTO Takashi