From owner-freebsd-hackers Wed Jul 1 06:14:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA14972 for freebsd-hackers-outgoing; Wed, 1 Jul 1998 06:14:52 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA14966 for ; Wed, 1 Jul 1998 06:14:51 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id GAA13621; Wed, 1 Jul 1998 06:14:25 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Willem Jan Withagen cc: hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued In-reply-to: Your message of "Wed, 01 Jul 1998 10:49:55 +0200." <199807010849.KAA25121@surf.IAE.nl> Date: Wed, 01 Jul 1998 06:14:25 -0700 Message-ID: <13617.899298865@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I've had some discussion with Terry about this, and one of the "options" > would be to include the *env pointer into the u-area, such that we know > where the user keeps his env. Well, just don't forget that the setenv() code in libc can change the value of environ at any time with a realloc(), so if you're going to copy it into the u_area you're also going to have to keep this copy in sync unless you also had plans on replacing environ. :) > How hard is it to get to the user's data from within the kernel? > And what about the copy penalty? It wouldn't be cheap, and I seriously pity the man who has to hack this code into namei() without seriously perturbing its optimizations for the "normal" case, but I think the speed/functionality tradeoffs would be also be acceptable in the long run. > Now the problem pointed out by Terry is that users are allowed to do nasty > stuff to their environment, and in the process "invalidate" the u-area *env. Yeah, I think it'll be enough to worry about the sanctioned functions for scribbling on *environ like setenv() and handle the people who are deliberately pounding on *environ with some kind of reasonable range checking. > 1) 'legacy' programs have no knowledge about this stuff. So resolving > links should make sense. Hmmm. readlink() would certainly do the expansion and prevent most legacy programs from having to even know about environment variable expansion in syminks, the question remaining as to what you do with variable names which are invalid or non-existant. Pass through the unexpanded token? Eliminate the token? Return NULL? :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message