Magic symlinks redux

Brooks Davis brooks at freebsd.org
Fri Aug 22 16:12:37 UTC 2008


On Fri, Aug 22, 2008 at 05:53:58PM +0200, Ivan Voras wrote:
> 2008/8/22 Brooks Davis <brooks at freebsd.org>:
> > On Fri, Aug 22, 2008 at 05:02:31PM +0200, Ivan Voras wrote:
> >> 2008/8/22 Brooks Davis <brooks at freebsd.org>:
> >>
> >> > I have an implementation derived from Andrey's port of the DragonFly
> >> > implementation which will be committed in the next month or two.  We
> >> > discussed it in detail at the dev summit and subject to a few more
> >> > changes and cleanup, it's ready to go.  It allows significantly more
> >> > flexibility than the NetBSD approach while avoiding many of the pitfalls
> >> > involved in variant symlinks.
> >>
> >> Does it also support special automatic variables like uid, hostname?
> >
> > No it does not.  There are two reasons for this.  First, it's basically
> > pointless since you can set system wide variables for things like
> > hostname and I have login_conf support to set things like uid or uname
> > variables.  Second, consider all the implications of @uid in the context
> > of setuid binaries.  This is hard to reason about and easy to get wrong.
> > As a result, I feel a model where variables are set per process and
> > follow fork is much less prone to error.
> 
> Firstly, it might be useless for your purpose but there are others.
> 
> 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, as set by
>                     setdomainname(3).
> 
>      @hostname      Expands to the machine's host name, as set by
>                     sethostname(3).
> 
>      @emul          Expands to the name of the current process's emulation.
> 
>      @kernel_ident  Expands to the name of the config(1) file used to generate
>                     the running kernel.
> 
>      @machine       Expands to the value of MACHINE for the system (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.
> 
>      @ruid          Exapnds to the real user-id of the process.
> 
>      @uid           Expands to the effective user-id of the process.
> 
> 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.
> 
> 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.

> Anyway, if the DFBSD framework is properly implemented, it shouldn't
> be hard to add these variables. If you don't want to, I volunteer.

I'm not completely opposed to adding a static namespace for system
wide variables.  I'm not at all keen on the @ruid and @uid variables
because I think they are risky.  My current feeling is that I'd like to
move ahead with my current implementation and then either add another
namespace or add this off to the side mostly as is.

> (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.

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.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20080822/6b84dcc1/attachment.pgp


More information about the freebsd-arch mailing list