Magic symlinks redux

[Garance A Drosehn]

At 11:13 AM -0500 8/22/08, Brooks Davis wrote:
>On Fri, Aug 22, 2008 at 05:53:58PM +0200, Ivan Voras wrote:
>
>  > If you read the NetBSD's documentation about magiclinks, you'll
>  > see this set of supported variables:
>  >
>  >      @domainname	Expands to the machine's domain name, ...
>  >      @hostname	Expands to the machine's host name, ...
>  >      @kernel_ident	Expands to the name of the config(1) file ...
>  >      @machine	Expands to the value of MACHINE
>  >			(equivalent to the output of ``uname -m'').
>  >      @machine_arch	Expands to the value of MACHINE_ARCH for
>  >			the system (equivalent to the output of
>  >			``uname -p'').
>  >      @osrelease	Expands to the operating system release
>  >			of the running kernel (equivalent to the
>  >			output of ``uname -r'').
>  >      @ostype	Expands to the operating system type of
>  >			the running kernel (equivalent to the
>  >			output of ``uname -s'').  This will
>  >                     always be ``NetBSD'' on NetBSD systems.
>
>  > Many of those are static and can be set on boot, but not all
>  > of them - for example machine and machine_arch may be different
>  > when running 32-bit processes on 64-bit machines. Domainname
>  > and hostname are different in jails.

I like the idea of having some of these mostly-static values,
although (as you note), we should to think about how these might
be effected within jails.  I have jails (really chroot areas)
which have different @osreleases than the running kernel, for
instance.

FWIW, I'd prefer to see the dragonfly-ish implementation over
the netbsd-ish implementation.

>  > Your example with uid is solved just like in userland (though
>  > the names are messed up) and reflect getuid() and geteuid().
>
>Small changes to the file system namespace can easily lead to security
>issues when applications assume the namespace is static.  This is
>particularly true for setuid binaries.

I am extremely uneasy about adding anything related to uid's or
gid's, or similar dynamic values.  I can't help but think tbat
any case where this would be useful, it would also be very risky
with-respect-to setuid() binaries.

>  > (I don't care about the syntax: @{something} vs ${something},
>  > though I think NetBSD made the better choice since these
>  > variables are not accessing the process environment).
>
>This is something I've been debating.  I've been leading toward
>something other than ${something}.  Either @{} or %{} or else
>going all the way to something like %%something%%.  I don't like
>the unanchored components netbsd uses.

This could easily degenerate into a bikeshed issue, but let me
at least say that I think we should avoid  "@varname".  That's
the syntax which AFS/OpenAFS/ARLA uses for their equivalent of
variant filename paths, and I think it would be good if we avoid
any confusion with that.

>One other option we discussed at the devsummit was requiring that
>the first character of a variant symlink be special to reduce
>parsing overhead.  I.e.  requiring that variant symlinks start
>with @ or % or something.

I'd like something with both a right and left delimiter, both
required.  Something where the two delimiters are different, and
easy to distinguish, and easy to "stack" (if for some reason we
wanted to allow that).  Stack in the sense of %{name1%{name2%}%},
where we can tell we would have to substitute the value for
"name2" before doing anything with the "name1"-ish part.  I don't
know that we need to actually support that ability, but if we do
(someday) want to support it, then I want delimiters where it
would be obvious what order the substitutions should occur in.

As far as the specific delimiters to pick, well, I'm sure anyone's
paint is as good as mine.  It will be nice to have this ability.

-- 
Garance Alistair Drosehn     =               drosehn at rpi.edu
Senior Systems Programmer               or   gad at FreeBSD.org
Rensselaer Polytechnic Institute;             Troy, NY;  USA