Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752296AbcCKUw4 (ORCPT ); Fri, 11 Mar 2016 15:52:56 -0500 Received: from mail-vk0-f50.google.com ([209.85.213.50]:36818 "EHLO mail-vk0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750987AbcCKUwx (ORCPT ); Fri, 11 Mar 2016 15:52:53 -0500 MIME-Version: 1.0 X-Originating-IP: [196.210.30.63] In-Reply-To: <56E32CD3.1010705@gmail.com> References: <56E327FF.1010103@nod.at> <56E3298A.1040008@nod.at> <56E32CD3.1010705@gmail.com> Date: Fri, 11 Mar 2016 22:52:52 +0200 Message-ID: Subject: Re: Variant symlink filesystem From: Cole To: "Austin S. Hemmelgarn" Cc: Richard Weinberger , LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1779 Lines: 41 On 11 March 2016 at 22:38, Austin S. Hemmelgarn wrote: > On 2016-03-11 15:24, Richard Weinberger wrote: >> >> Am 11.03.2016 um 21:22 schrieb Cole: >>> >>> If I remember correctly, when we were testing the fuse version, we hard >>> coded >>> the path to see if that solved the problem, and the difference between >>> the env lookup >>> code and the hard coded path was almost the same, but substantially >>> slower than >>> the native file system. >> >> >> And where exactly as the performance problem? >> >> Anyway, if you submit your filesystem also provide a decent use case for >> it. :-) >> > I don't know that this qualifies as a use case, but I've seen a number of > capability based systems that have a similar concept they usually refer to > as 'context dependent symbolic links'. In such cases, the resolution is > usually based on what capabilities you posses, and is more of a mapping than > a value expansion most of the time, but such usage could be emulated (albeit > much less securely) with this. If this could be extended to expand other > values (for example, process bit width, or SELinux context, or even what > namespace the process is in), it could provide the same functionality almost > as securely. The implementation doesn't necessarily have to continue to work with env variables. On FreeBSD, the variant symlinks function by using variables stored in kernel memory, and have a hierarchical lookup, starting with user defined values and terminating with global entries. I am not aware of such functionality existing on linux, but if someone could point me at something similar to that, I would much prefer to use that, as there are issues with variables that are exported or modified during process execution. Regards /Cole