search

gramineproject / gramine

A library OS for Linux multi-process applications, with Intel SGX support
GNU Lesser General Public License v3.0
587 stars 193 forks source link

Proper emulation of magic symlinks (e.g. in procfs) #1872

Open mkow opened 4 months ago

mkow commented 4 months ago

Description of the problem

Some symlinks on Linux FS are not really symlinks, and we have to emulate that properly.

Example: a pipe in /proc/self/fd/XX pretends to be a symlink (file type is S_IFLNK), but readlink returns a string in form of pipe:[29335264]. Despite this, it's still possible to open this file on Linux, but following it as a symlink is impossible.

Currently in Gramine we return those weird strings via readlink(), but when trying to open them our path resolver tries to follow them, thus failing to open the file.

We probably need a new type of dentry for these fake links, or some special flag which would prevent the path resolver from following them.

// This is a split-out from #1267.

Steps to reproduce

Run cat some_file | cat /proc/self/fd/0 in Bash under Gramine.

Expected results

### Actual results `cat: /proc/self/fd/0: No such file or directory` printed to stderr. ### Gramine commit hash 64cd864da9705dc71155c6ab2d87ef6e8794976b
dimakuv commented 4 months ago

Currently in Gramine we return those weird strings via readlink()

In particular, this code does it:

https://github.com/gramineproject/gramine/blob/b7ffa83a4203bdc2b560cbfef140c0e8ab6b7a58/libos/src/fs/proc/thread.c#L273-L293

However, there is no inode information, just a hard-coded [?]. That's not ideal; but probably real-world apps don't care and don't use the inode numbers like this.

We probably need a new type of dentry for these fake links, or some special flag which would prevent the path resolver from following them.

I am afraid we'll have to introduce proper dentry objects for these (well, without any real path, but still pointing to a valid inode). Otherwise this will become full of special cases. At the same time, this will probably a big change, and I'd say it's not worth it unless we have a real app (that cannot circumvent this limitation).

dimakuv commented 4 months ago

At the same time, this will probably a big change, and I'd say it's not worth it unless we have a real app (that cannot circumvent this limitation).

I take my words back. We already have such an application, and it is Bash: https://github.com/gramineproject/gramine/issues/1267

So maybe implementing it should be a higher priority.