Re: Variant symlinks [was Re: symlink question]
In article 53425.929320...@zippy.cdrom.com you write: And have /usr/bin point to /binaries/i386/bin or /binaries/mips/bin And before people jump on me, let me just clarify in advance that I was not meaning to imply that Apollo ever used the x86 architecture. They didn't. It was just an example. :) Well sort of. :-) It could do windoze emulation on their poor 68K boxes. But you'd have to be a very patient (or desperate) person to use that. --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 9.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Variant symlinks [was Re: symlink question]
As Willem Jan Withagen wrote ... In article 53425.929320...@zippy.cdrom.com you write: And have /usr/bin point to /binaries/i386/bin or /binaries/mips/bin And before people jump on me, let me just clarify in advance that I was not meaning to imply that Apollo ever used the x86 architecture. They didn't. It was just an example. :) Well sort of. :-) It could do windoze emulation on their poor 68K boxes. But you'd have to be a very patient (or desperate) person to use that. Patient... yeah. I used to run hardware simulations on a DN3000 (68020/12), with a network connected hardware modeller. Cute, at that time.. -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: symlink question
On Sunday, 13th June 1999, Chuck Youse wrote: Forgive my ignorance, but what exactly is meant by a variant link, and what might one be used for? Abused, not used. A number of incredibly dodgy things can be done with symlinks that point here at one moment and there at another moment based on the current value of some environment variable, or other hidden system variable. I cough up a lung every time this topic is raised. Variant symlinks have caused me grief (Pyramid OSx) and never joy. I hope it fails yet again to appear in FreeBSD. Just think of the new security holes for a start. Stephen. Oh, namei! What have they done to thee? -- John Mackin, on seeing Apollo's variant symlinks. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: symlink question
symlinks have caused me grief (Pyramid OSx) and never joy. I hope it fails yet again to appear in FreeBSD. Just think of the new security holes for a start. Name one, please. You can currently point a symlink anyplace you like; whether the user has permission to *read* or execute the target of the link, however, is where the genuine system administration takes over. How the actual value is derived shouldn't make that much difference. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: symlink question
On Mon, 14 Jun 1999, Jordan K. Hubbard wrote:
symlinks have caused me grief (Pyramid OSx) and never joy. I hope it fails
yet again to appear in FreeBSD. Just think of the new security holes for a
start.
Name one, please. You can currently point a symlink anyplace you
like; whether the user has permission to *read* or execute the target
of the link, however, is where the genuine system administration takes
over. How the actual value is derived shouldn't make that much
difference. :)
First try: Suppose foo depends on /usr/local/etc/foo.conf.
/usr/local/etc is a link to /usr/local/${ARCH}/etc. User does
export $ARCH=../../home/user, so /usr/local/etc/foo.conf is now in
their home directory. Depending on how poorly written foo is
written, it may be possible for the user to get foo to do things
it wouldn't normally. There a bunch of these sorts of things
lurking here. Clearly, navigation up the tree can't be allowed,
at least for processes operating with increased privs. There are
probably some other path subversion issues, or potential issues,
lurking in this. This is not to say this isn't a good idea. I
can think of serveral uses that would make my life easier.
David Scheidt
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: symlink question
On Monday, 14th June 1999, Jordan K. Hubbard wrote:
symlinks have caused me grief (Pyramid OSx) and never joy. I hope it fails
yet again to appear in FreeBSD. Just think of the new security holes for a
start.
Name one, please. You can currently point a symlink anyplace you
like; whether the user has permission to *read* or execute the target
of the link, however, is where the genuine system administration takes
over. How the actual value is derived shouldn't make that much
difference. :)
Yes, symlinks caused (still cause?) havoc when introduced! And with
variant symlinks, you lose the ability to statically verify where things
go. A safe symlink (right now) becomes a dangerous one not when the file
system is changed, but when some transient variable changes. I don't like
that at all. I don't want to have to think through all the consequences.
You might consider this sort of shifting of the goal posts (the subtle change
to the behaviour of absolutely every program) as a minor inconvenience, and
acceptable in order to gain the benefits of variant links. I don't think
that way, partially because I don't see them as a real benefit, with more
wow effect than real utility. Everyone points out the /${ARCH}/bin
use, but that can be done in other ways (eg just set PATH) that don't
cost much (admin time or cpu time).
Stephen.
PS On second thoughts, I think Mackin was pointing and exclaiming at a
Tektronix workstation. Did they have variant links?
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: symlink question
dsche...@enteract.com (David Scheidt) writes:
First try: Suppose foo depends on /usr/local/etc/foo.conf.
/usr/local/etc is a link to /usr/local/${ARCH}/etc. User does
export $ARCH=../../home/user, so /usr/local/etc/foo.conf is now in
their home directory. Depending on how poorly written foo is
Eww, I don't like the idea of using environment variables this way.
The kernel shouldn't rely on them, they are a userland thing except
during execve. Environment variables aren't even visible to the
kernel in the process that sets them.
Variant symlinks don't need to be controlled through environment
variables. If there is a specific use in mind for variant symlinks,
the mechanism for configuring them should be chosen with consideration
for that. (Even if variant symlinks could be environment variables,
there should be ones that are based on some hard-wired info and
system-wide variant symlinks should only use environment variables
when user-modifiability is specifically desirable. Your example is
obviously a case of improper use.)
If there is no specific use in mind for variant symlinks, other than
to have fun magic thingies around to play with that *can* be used for
such-and-such, then implementing them is not a particularly good idea.
For example, Lites had variant symlinks with keywords that were
internally resolved to the architecture/system name or the name of the
system being emulated.
For Lites, this was much better than something equivalent to FreeBSD's
/compat hacks, because emulated systems were equal, and the root
partition could be shared with the real system. For FreeBSD, the
current approach is probably better, because emulated systems are
optional exceptions.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: symlink question
symlinks have caused me grief (Pyramid OSx) and never joy. I hope it fails yet again to appear in FreeBSD. Just think of the new security holes for a start. Name one, please. You can currently point a symlink anyplace you like; whether the user has permission to *read* or execute the target of the link, however, is where the genuine system administration takes over. How the actual value is derived shouldn't make that much difference. :) - Jordan My biggest problem with variant symlinks (which I've preached on before) is the following scenario: o) User A runs program P which takes advantage of a variant symlink in some fashion (either in finding P or finding some data P needs, etc...) o) User B runs program P which fails miserably. o) The sysadmin notes that the machines are the same, the symlinks are the same... then has to track down user B, and has to determine what variant symlinks P has been (perhaps even unaware to the designers of P) using and then has see what in user B's environment is causing this problem. Muliply B by several hundred... We would have problems like that on our Apollos; learning the hard way to avoid variant symlinks... just to ensure the environment was as expected.You don't have these same questions with plain symlinks. And, if the symlink changes, it's quite easy to see that it changed... So - I'd say that variant symlinks are like many other things, it's really easy to shoot yourself in the foot.. In my opinion variant symlinks make it too easy. Sometimes nifty things don't need to be done. I'd suggest that if they were implemented in FreeBSD - we leave the support 'off' by default, with a sysctl variable to enable them. When a user posts that his XXX/YYY/ZZZ directory has gone away we can ask, are variant symlinks turned on? and have a good first guess as to the culprit. Just my thoughts - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: Variant symlinks [was Re: symlink question]
-Original Message- From: Jordan K. Hubbard [SMTP:j...@zippy.cdrom.com] Sent: Monday, June 14, 1999 2:32 AM Cc: Chuck Youse; Marc Ramirez; hack...@freebsd.org Subject: Re: Variant symlinks [was Re: symlink question] And have /usr/bin point to /binaries/i386/bin or /binaries/mips/bin And before people jump on me, let me just clarify in advance that I was not meaning to imply that Apollo ever used the x86 architecture. They didn't. It was just an example. :) [ML] My last Apollo (with an HP badge on it) was an MC 68040 with a whopping 16 Megs of RAM and 1 Gig of disk. It was running DomainOS, though :) Believe me, it was an improvement over MicrovaxII running Ultrix. Ah, the olden days... /Marino - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: symlink question
On Sun, 13 Jun 1999, Chuck Youse wrote:
Forgive my ignorance, but what exactly is meant by a variant link, and
what might one be used for?
In my fantasy world, a variant symlink is kind of a way of putting a
search path into a symbolic link, so that if you had an environment
variable E=a:b:c, and you had a symbolic link created with
ln -s /some/where/\${E}/foo bar
when you execute a command like
more bar/baz.txt
it would look for /some/where/a/foo/bax.txt, then
/some/where/b/foo/baz.txt, then /some/where/c/foo/baz.txt.
It's akin to what the unionfs tries to do, but it doesn't care about
creating total transparency, and it doesn't mask directories, and changes
to one process's search order don't affect other process's search orders,
so you don't have to do all those machinations with loopback mounts and
things like that. It's much more along the lines of VMS's logicals, if
yoy know of those.
As for uses, in my fantasy world, I personally would be using it for
system testing where I have a rather large base system which gets modified
per customer. export CUSTOMER=foo; gosystem would be so nice...
Marc.
Chuck Youse
Director of Systems
cyo...@cybersites.com
-Original Message-
From: Marc Ramirez mr...@gbtb.com
To: hack...@freebsd.org hack...@freebsd.org
Date: Sunday, June 13, 1999 1:12 PM
Subject: symlink question
Sorry if I'm bothering you busy folk unnecessarily...
If I wanted to add variant symlinks, would that just require modifications
to namei, or is that way too simplistic?
Thanks,
Marc.
--
Marc Ramirez - Owner Great Big Throbbing Brains
mr...@gbtb.com http://www.gbtb.com
Our brains throb, so yours won't have to!
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
--
Marc Ramirez - OwnerGreat Big Throbbing Brains
mr...@gbtb.com http://www.gbtb.com
Our brains throb, so yours won't have to!
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Variant symlinks [was Re: symlink question]
On Sun, 13 Jun 1999, Jordan K. Hubbard wrote: Forgive my ignorance, but what exactly is meant by a variant link, and what might one be used for? Gee, it's refreshing to see someone other than myself bringing this subject up. :) Well, I'd like to add versioning, too, but _that's_ hard! :) Marc. -- Marc Ramirez - OwnerGreat Big Throbbing Brains mr...@gbtb.com http://www.gbtb.com Our brains throb, so yours won't have to! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: symlink question
Chuck Youse wrote:
Forgive my ignorance, but what exactly is meant by a variant link, and
what might one be used for?
A symlink that has a variable name embedded in it. It can be quite
useful at times; consider a symlink such as: /usr/local/bin/bash -
/usr/local/{karch}/bin/bash, where {karch} can be automagically
expanded into i.e. i386-FreeBSD3.1 or sparc-NetBSD1.4 or hppa-hpux10.
--
Where am I, and what am I doing in this handbasket?
Wes Peters Softweyr LLC
http://www.softweyr.com/~softweyr w...@softweyr.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Variant symlinks [was Re: symlink question]
In message pine.bsf.3.96.990614120238.366e-100...@server.ghostgbtb.com Marc Ramirez writes: : Well, I'd like to add versioning, too, but _that's_ hard! Versioning wouldn't be too hard to add to a filesystem. Name lookup would be impacted. The act of creating a new version would just be the creat(2) system call, or open with the O_CREAT bit set (and maybe with the O_TRUNC bit too). However, adding utilities to deal with all these new versions might take a lot of time since various versioning schemes have been implemented in userland over the years (all the foo~ or foo~3~ files from us emacs users, for example). I don't know if it would be worth it to actually do this, but it would make an interesting kernel hacking project for someone wishing to learn about the vfs layer. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
symlink question
Sorry if I'm bothering you busy folk unnecessarily... If I wanted to add variant symlinks, would that just require modifications to namei, or is that way too simplistic? Thanks, Marc. -- Marc Ramirez - OwnerGreat Big Throbbing Brains mr...@gbtb.com http://www.gbtb.com Our brains throb, so yours won't have to! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: symlink question
In article pine.bsf.3.96.990613141052.366b-100...@server.ghostgbtb.com you write: Sorry if I'm bothering you busy folk unnecessarily... If I wanted to add variant symlinks, would that just require modifications to namei, or is that way too simplistic? I've done that part with help of Mike Smith and others. I still have the changes around somewhere. it was the simpeler part of the job. The harder part is to get something to be usable to replace the variable part with. There has been some discussion on how to get information to the kernel on the variant part. And what kind of problems would go with that. I started on an excursion into sysctl to make it much more dynamic. And use the information stored in there as subsitute values for the variant-links. But since I ran out of holyday time, it has been shelved. The discussions should still be in the archives. Most probably under variant links. --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 9.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: symlink question
Forgive my ignorance, but what exactly is meant by a variant link, and what might one be used for? Chuck Youse Director of Systems cyo...@cybersites.com -Original Message- From: Marc Ramirez mr...@gbtb.com To: hack...@freebsd.org hack...@freebsd.org Date: Sunday, June 13, 1999 1:12 PM Subject: symlink question Sorry if I'm bothering you busy folk unnecessarily... If I wanted to add variant symlinks, would that just require modifications to namei, or is that way too simplistic? Thanks, Marc. -- Marc Ramirez - Owner Great Big Throbbing Brains mr...@gbtb.com http://www.gbtb.com Our brains throb, so yours won't have to! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Variant symlinks [was Re: symlink question]
Forgive my ignorance, but what exactly is meant by a variant link, and
what might one be used for?
Gee, it's refreshing to see someone other than myself bringing this
subject up. :)
Variant symlinks, which many of us fell in love with back in our Apollo
days, are essentially just symlinks with a level of variable expansion
added in. E.g. back on the Apollo, you could do thinks like this:
ln -s /usr/bin '/binaries/${ARCH}/bin'
And have /usr/bin point to /binaries/i386/bin or /binaries/mips/bin
depending on the user's $ARCH environment variable, ostensibly set by
default by the shell but also user-modifiable with setenv. Many other
things involving architecture, timezone or natural language neutrality
are also obviously possible with this mechanism, this is just one
example.
The problem with doing this under FreeBSD always arises when one
contemplates getting at the user's environment from the context of
namei() - Apollo was able to see this problem coming and plan for it
in advance, Unix did not and it's not quite so trivially contemplated
here. ;)
That, in turn, generally leads folks away from the environment and
into a more sysctl-based (or other analogous) mechanism for setting
symlink variables, that stage generally bogging down over the question
of implementing user, group and system-wide variable spaces when all
the VMS people jump into the discussion and make a good case for this.
The current sysctl implementation assumes just one system-wide
variable space.
Good luck on this iteration, guys - that's all I can say. :-)
It's a worthy feature, doing it truly correctly is simply
hard.
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Variant symlinks [was Re: symlink question]
And have /usr/bin point to /binaries/i386/bin or /binaries/mips/bin And before people jump on me, let me just clarify in advance that I was not meaning to imply that Apollo ever used the x86 architecture. They didn't. It was just an example. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
