Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1356177

Re: Variant symlink filesystem

From "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
Newsgroups linux.kernel
Subject Re: Variant symlink filesystem
Date 2016-03-11 21:40 +0100
Message-ID <rbC0N-3ei-3@gated-at.bofh.it> (permalink)
References (1 earlier) <rbBxM-2Xc-9@gated-at.bofh.it> <rbBHs-32u-9@gated-at.bofh.it> <rbBHs-32u-13@gated-at.bofh.it> <rbBR8-38o-7@gated-at.bofh.it> <rbBR8-38o-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw

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.

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Variant symlink filesystem Cole <cole@opteqint.net> - 2016-03-11 17:30 +0100
  Re: Variant symlink filesystem "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-03-11 17:50 +0100
  Re: Variant symlink filesystem Richard Weinberger <richard.weinberger@gmail.com> - 2016-03-11 21:10 +0100
    Re: Variant symlink filesystem Cole <cole@opteqint.net> - 2016-03-11 21:20 +0100
      Re: Variant symlink filesystem Richard Weinberger <richard@nod.at> - 2016-03-11 21:20 +0100
        Re: Variant symlink filesystem Richard Weinberger <richard@nod.at> - 2016-03-11 21:30 +0100
          Re: Variant symlink filesystem "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-03-11 21:40 +0100
            Re: Variant symlink filesystem Cole <cole@opteqint.net> - 2016-03-11 22:00 +0100
              Re: Variant symlink filesystem Al Viro <viro@ZenIV.linux.org.uk> - 2016-03-11 23:00 +0100
                Re: Variant symlink filesystem Cole <cole@opteqint.net> - 2016-03-11 23:10 +0100
                Re: Variant symlink filesystem Al Viro <viro@ZenIV.linux.org.uk> - 2016-03-11 23:30 +0100
                Re: Variant symlink filesystem Cole <cole@opteqint.net> - 2016-03-11 23:40 +0100
                Re: Variant symlink filesystem David Lang <david@lang.hm> - 2016-03-11 23:50 +0100
                Re: Variant symlink filesystem Cole <cole@opteqint.net> - 2016-03-12 00:00 +0100
                Re: Variant symlink filesystem David Lang <david@lang.hm> - 2016-03-11 23:50 +0100
          Re: Variant symlink filesystem Cole <cole@opteqint.net> - 2016-03-11 21:40 +0100
            Re: Variant symlink filesystem Richard Weinberger <richard@nod.at> - 2016-03-11 21:40 +0100
            Re: Variant symlink filesystem David Lang <david@lang.hm> - 2016-03-11 23:40 +0100
        Re: Variant symlink filesystem Cole <cole@opteqint.net> - 2016-03-11 21:30 +0100

csiph-web