Date: Sat, 4 Jul 1998 20:28:42 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: drosih@rpi.edu (Garance A Drosihn) Cc: hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued Message-ID: <199807042028.NAA01169@usr02.primenet.com> In-Reply-To: <v04011721b1c20a7a03ab@[128.113.24.47]> from "Garance A Drosihn" at Jul 3, 98 01:02:23 am
next in thread | previous in thread | raw e-mail | index | archive | help
> To quote from the article written by Terry:
> > For example, we could have made the /usr/lib/aout change appear
> > to have zero impact.
>
> My guess is that no one is going to make the aout change appear to
> have zero impact by assuming *every* *end-user* is individually
> going to create symbolic links and set environment variables.
Actually, that is not what I intended to happen.
What I intended to happen was that the variable would be set in the
process logical name table by the execuation class loader (which
knows this information). If you attempt to execve(2) a program,
and it is an a.out program, you get a.out variant link resoloution
for it.
So if I type "ldconfig", and "ldconfig" is an a,out program, then
it will reference the files in /usr/lib -> /usr/libx/${#BINFORMAT}
(or however the link is arranged).
I chose the # as a namespace escape to place system variable into
an environment because:
1) You can't create them with a leading '#', normally, in a
shell.
2) You can't create them with a leading '#', normally, using
the setenv(3)/putenv(3) interface to the libc.
3) Using:
set > x
...
...
. x
Works as expected: the lines are treated as comments, and
not attempted to be set, as use of "@" or some other prefix
would be, and it is improper for programs to set into the
system space.
I expect the list of "system" valiables would either be a view onto
the sysctl namespace (for the system logical name table, nominally
belonging to the "init" process), or set per process group and per
process as an override by the kernel (ie: for things like an a.out
binary calling fork(2) then the child calling execve(2) to start a
Linux branded ELF binary).
In no case would this perticular soloution result in the end user
setting anything themselves.
> No, I
> suspect some administrator or system-developer is the person making
> the decision to create that particular symbolic link... And once
> they do, then *every* end user had better not choose that particular
> environment variable unless they fully understand how it's being used
> for this symbolic link (even though ideally they wouldn't even know
> the link exists).
As you can see, for kernel set variables derived from information
beyond the user's control, a namespace escape that in inaccessible
to the standard environment interfaces (except "char **environ", and
it's deprecated by the design) there is no danger.
> Actually, though, I think that what I'm proposing is really just
> an alternative to environment variables (not just "environment
> variables for symbolic links", but "an alternative to environment
> variables for holding configuration settings"). Perhaps that
> wouldn't be too hard to do a simple cut of?
I do not like the idea of inventing "yet another place to store
configuration information"; I would *prefer* a soloution that
unifies the environment.
Since the kernel can't go to the envronment (if "char **environ" is
*ever* extended), the environment can go to the kernel. This seems
to be an obvious soloution to me, and it just happens to solve a
slew of other problems (the "manipulate parent environmnet after a
vfork" problem, the "manipulate an unrelated processes environment,
for which you have the uid to do the job" problem -- ie: DISPLAY,
among others, etc.).
> To get the kernel to correctly *use* environment variables for
> symbolic links is going to take some work (even if everyone agrees
> it's the best of all ideas), and perhaps an alternative would be
> less work to do. If so, I can get away with all this babbling
> without irritating any person who is actually doing the useful
> work on it... :-)
I have implemented the code on an experimental basis. I am not
terrifically happy with needing a new system call, nor am I happy
with (basically) moving some of the existing libc code into the
kernel; I'd prefer a lighter weight approach. I also have not
resolved the exec(3) family's passing of "char **environ" to the
execve(2) system call issues (in particular, my previous speculation
about whther or not you are allowed to pass a NULL environment pointer,
or must pass a NULL-valued real memory pointer remains unknown, so
the "magic cookie" for the default "inherit from parent" is still
not nailed down.
But the code works.
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?199807042028.NAA01169>