All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Richard Weinberger <richard@nod.at>, Cole <cole@opteqint.net>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: Variant symlink filesystem
Date: Fri, 11 Mar 2016 15:38:43 -0500	[thread overview]
Message-ID: <56E32CD3.1010705@gmail.com> (raw)
In-Reply-To: <56E3298A.1040008@nod.at>

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.

  parent reply	other threads:[~2016-03-11 20:39 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-11 16:20 Variant symlink filesystem Cole
2016-03-11 16:44 ` Austin S. Hemmelgarn
2016-03-11 20:04 ` Richard Weinberger
2016-03-11 20:15   ` Cole
2016-03-11 20:18     ` Richard Weinberger
2016-03-11 20:22       ` Cole
2016-03-11 20:24         ` Richard Weinberger
2016-03-11 20:32           ` Cole
2016-03-11 20:36             ` Richard Weinberger
2016-03-11 22:27             ` David Lang
2016-03-11 20:38           ` Austin S. Hemmelgarn [this message]
2016-03-11 20:52             ` Cole
2016-03-11 21:51               ` Al Viro
2016-03-11 22:03                 ` Cole
2016-03-11 22:24                   ` Al Viro
2016-03-11 22:31                     ` Cole
2016-03-11 22:48                       ` David Lang
2016-03-11 22:54                         ` Cole
2016-03-11 22:38                   ` David Lang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56E32CD3.1010705@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=cole@opteqint.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=richard@nod.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.