Date: Fri, 3 Jul 1998 01:18:39 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Terry Lambert <tlambert@primenet.com> Cc: jkh@time.cdrom.com, hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued Message-ID: <v04011720b1c1f3fcba85@[128.113.24.47]> In-Reply-To: <199807030000.RAA14014@usr09.primenet.com> References: <v0401171cb1c1b6683f8e@[128.113.24.47]> from "Garance A Drosihn" at Jul 2, 98 06:50:46 pm
next in thread | previous in thread | raw e-mail | index | archive | help
At 12:00 AM +0000 7/3/98, Terry Lambert wrote:
>> Certainly it is an attractive idea to base symlinks on environment
>> variables, but maybe we should ask ourselves how hard it would be
>> to implement a "nice clean private namespace somewhere". I think
>> we'll be happier with the separate namespace, something which isn't
>> disrupted as readily and as often as the user environment.
>
> A namespace is a namespace. Your arguments apply no matter where the
> namespace is located, so long as you permit the user to modify it
> at all.
No, I don't think they do (just talking about my own opinion, of
course). A user (or a script) can create and modify environment
variables for whatever reason they happen to need a variable for,
and in doing so they clobber some symlink that they may not even
realize is referencing an environment variable.
Instead, let us say there was a unix command which modified some
other namespace. This other namespace is a database of sorts, so
we'll call the unix command, oh, say, 'dwrite' (*). I, as a user,
am not going to type in
dwrite FileSystem somekey somevalue
without having some understanding that this might effect symbolic
links. Yes, I can still royally screw up all kinds of applications
by typing that command in, but it's much less likely that I'd do
that without realizing the *scope* of what it is that I'm changing.
I'm not saying we should put up some barrier so end-users can not
hang themselves by changing a symlink value. I am saying that
end-users (or people who write scripts used by end users) can and
do use all kinds of variable names which they pick out of thin air
because the name sounds like a good name. They should be able to
continue to do that without causing wild things to happen to any
filesystem accesses.
And while I don't consider myself a wizard unix programmer (and I'm
sure no one here does either... :-), I have written programs which
purposely setup a specific user environment before exec-ing some
other program. When I have done that, I have never taken any time
to wonder "gee, I wonder if this will screwup access to some file
somewhere, because a symbolic-link that this program *unknowingly*
references will not see an environment variable that the link needs
for it to work correctly".
> For example, we could have made the /usr/lib/aout change appear to
> have zero impact. We could also have done a large number of other
> things with apparently zero impact, that would allow us to build
> multiple targets on the same machine, for example, something that
> the current build environment is not good at.
I well understand how useful it could be. I think the work already
done towards variant symbolic links is pretty encouraging. I am only
arguing that it is a bad idea to have symbolic links key off
environment variables.
Let's say freebsd could make the /usr/lib/aout change based on some
symbolic-link attribute. This sounds good to me. Now let's say some
morass of scripts and programs that you're porting from somewhere else
just happen to modify the very environment variable that someone else
(not you personally) happened to choose for that aout-related symlink.
Wherever that script or application changes the value, you can be
sure it will not have a commment:
OBJFMT=no # Break important symbolic link in freebsd,
# and no other operating system but freebsd,
# thus causing incrediable confusion.
If it has any comments, it's going to say:
OBJFMT=no # Assume the file we are reading is not an
# object module.
I am not arguing against dynamic values. I am not arguing that
users should only be allowed to use variable-names which are
hardcoded into the kernel. I am only arguing that we will
probably see more headaches if environment variables can effect
the target of symlinks than we will see "clever things" which
*require* that environment variables can effect symbolic links.
> the current build environment is not good at. There are
> numerous other examples that I can bore you with, if you
> insist... 8-).
>From where I am sitting, you are providing excellent arguments
against a position that I am not taking. They are very compelling
for the position you have focused on, but as near as I can tell
they miss the point of the position I am trying to advocate.
(hopefully that doesn't come across as snotty, but I really do
agree that you have given examples of very useful things, and I
honestly feel those examples have absolutely nothing to do with
the position I'm trying to take. In my "idealized implementation"
(whatever that means...), I fully expect one could and should be
able to do every single example that you've suggested so far)
So, either there is something about the implementation you're
thinking of which I'm just not getting (and thus it's not as
prone to headaches as I fear), or there is something about my
position that you are not getting.
In either case, I don't need more examples of how variant
symlinks could be very useful. I understand that part.
---
Garance Alistair Drosehn = gad@eclipse.its.rpi.edu
Senior Systems Programmer or drosih@rpi.edu
Rensselaer Polytechnic Institute
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?v04011720b1c1f3fcba85>