Date: Fri, 22 Aug 2008 17:53:58 +0200 From: "Ivan Voras" <ivoras@freebsd.org> To: "Brooks Davis" <brooks@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux Message-ID: <9bbcef730808220853q22666b44n5ca2b7add991191f@mail.gmail.com> In-Reply-To: <20080822153945.GC57443@lor.one-eyed-alien.net> References: <g8kv7v$sp2$1@ger.gmane.org> <20080822150020.GA57443@lor.one-eyed-alien.net> <9bbcef730808220802pa84b597u457100a23b03a80c@mail.gmail.com> <20080822153945.GC57443@lor.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
2008/8/22 Brooks Davis <brooks@freebsd.org>:
> On Fri, Aug 22, 2008 at 05:02:31PM +0200, Ivan Voras wrote:
>> 2008/8/22 Brooks Davis <brooks@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().
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 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).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9bbcef730808220853q22666b44n5ca2b7add991191f>