[OpenAFS-devel] Re: OpenAFS: conventions for new @sys? (rs_aix43 s390_linux22)

[Sam Hartman]

>>>>> "Nathan" == Nathan Neulinger <nneul@umr.edu> writes:

    Nathan> Russ Allbery wrote:
    >>  Nathan Neulinger <nneul@umr.edu> writes:
    >> 
    >> > How bout a much more capable facility than @sys... Extend
    >> that concept > into what the old apollo workstations had -
    >> dynamic symlinks. Why not > make that part of AFS. i.e. support
    >> more than just @sys.
    >> 
    >> > For example, alot of sites would probably find '@acsys' to be
    >> useful to > do the autoconf determined sys type.
    >> 
    >> Er... for what?
    >> 
    >> The output of config.guess is useful for FSF build tools and
    >> for doing some system-specific checks in configure, and that's
    >> pretty much it.

    Nathan> Well, building architecture specific trees of products
    Nathan> could be quite handy, particularly if you start building
    Nathan> versions optimized to particular CPUs, etc.

    Nathan> Or, mapping product trees according to particular
    Nathan> environment variable choices that would be completely
    Nathan> transparent to the calling product.


One significant advantage of the current implementation of @sys is
that it is universal, works, and there are a few values to choose
from.  I am concerned about the possible problems associated with
multiple dynamic symlink primitives.  This is especially very
problematic as new platforms are dded especially in this age of binary
emulation and fast changing software.  It's easy to get into a
situation where my  client can't easily run some software because your idea about the abilities of my client are different from its actual capabilities.q

Also, consider situations where some users build some dynamic symlink support into their clients and others do not.  Consider that for a fairly long time we will have stock Transarc clients that only support @sys.

Finally, consider potential security and information leaks associated with environment variables.  I might be able to find out information on a webserver's PATH and other environment variables by sending it URLs pointing to a fileserver I control.  I can't think of a way of exploiting this now, but such unexpected semantics have tended to security problems in the past.q