From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 15:53:59 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3E18106567E for ; Fri, 22 Aug 2008 15:53:58 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by mx1.freebsd.org (Postfix) with ESMTP id C505C8FC1A for ; Fri, 22 Aug 2008 15:53:58 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so870552rvf.43 for ; Fri, 22 Aug 2008 08:53:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=AE4ubnFEfdhaiN4P47ZgzIhuXbckzcfALMoDPl8AB30=; b=RUmN36dan1wSPSCJcK+BH9/Re6GPUyO1eqLyN0g8DMHlkKW/7rR4cSdOZ7zfDCbQqc hTFcikcOnUTnFit38ulkiJYFHmIBikKJSbRiPQO+cD/QF4WTOYw7z8yE+yOciYrS0lpZ mlQsTLT1lvHHUusQVPZoZRYrotduGNXhlSvaM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=iJIxPM5adOm6QmdhThb9nS6dH85OlE/3FL2wPLHpUPcc6kiLyuIsAUFKnjG9ISp8wU jAOWUeSEM/+bZRn6Y9mGV6S1MSXCSrR+Lt/34COK2BKH1jvJHBYlQWwaj+s/IqlfhdYi wCpNtE/X+GkW18V8vAup6VQ6slwSRjt4bQcLA= Received: by 10.141.70.18 with SMTP id x18mr595534rvk.284.1219420438135; Fri, 22 Aug 2008 08:53:58 -0700 (PDT) Received: by 10.141.153.13 with HTTP; Fri, 22 Aug 2008 08:53:58 -0700 (PDT) Message-ID: <9bbcef730808220853q22666b44n5ca2b7add991191f@mail.gmail.com> Date: Fri, 22 Aug 2008 17:53:58 +0200 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Brooks Davis" In-Reply-To: <20080822153945.GC57443@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080822150020.GA57443@lor.one-eyed-alien.net> <9bbcef730808220802pa84b597u457100a23b03a80c@mail.gmail.com> <20080822153945.GC57443@lor.one-eyed-alien.net> X-Google-Sender-Auth: 77a7530c46fc1b24 Cc: freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 15:53:59 -0000 2008/8/22 Brooks Davis : > On Fri, Aug 22, 2008 at 05:02:31PM +0200, Ivan Voras wrote: >> 2008/8/22 Brooks Davis : >> >> > 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).