Date: Thu, 2 Jul 1998 00:12:19 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: wjw@surf.IAE.nl, hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued Message-ID: <199807020012.RAA28590@usr07.primenet.com> In-Reply-To: <13617.899298865@time.cdrom.com> from "Jordan K. Hubbard" at Jul 1, 98 06:14:25 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. :) Well, technically... "extern char **environ" is not required to be updated by setenv(3). I would suggest making getenv(3)/putenv(3)/getenv(3)/unsetenv(3) operate on a lnm_ (logical name) interface, which in turn operates on a multiplex system call (lnm(LNM_GET, ...), etc.). This would effectively hang the environment off the proc struct in data pages belonging to the process but accessible to the kernel. The symbolic links could be accessed from there. This would, of course, leave things that directly reallocate environ instead of using setenv() hanging out to dry. It would also, if the variant "main(ac, av, envp)" is used, yield an envp that was, effectively, read-only. The execve() call would be left intact. I would take a NULL-valued envp argument to execve to mean "copy from parent" (the current semantic is undefined, according tot he man page; if a NULL is legal, then use (((char *)NULL) - 1) as the inheritance escape, instead. > > 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. Or let them twiddle it, but ignore them. ;-). > 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? :-) My preference?: I. Look in my env II. Look in the process group leader's env III. Look in init's env IV. replace them with "" (zero length string, just as sh does). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807020012.RAA28590>