Messages in this thread | | | Date | Fri, 11 Mar 2016 22:52:52 +0200 | Subject | Re: Variant symlink filesystem | From | Cole <> |
| |
On 11 March 2016 at 22:38, Austin S. Hemmelgarn <ahferroin7@gmail.com> 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
| |