Issues with `/proc/self/exe`

[DUOLabs333]

I mounted /proc with bindfs. However, when running a dotnet 5.0 app, I get Failed to resolve full path of the current executable [/proc/self/exe]

My command: [sudo] bindfs -o [suid,]dev

[DUOLabs333]

This also affects yarn which reads /proc/self/stat

[DUOLabs333]

It seems that bindfs does not understand that stat is not an empty folder, but rather just exposes a 0-byte file instead.

[DUOLabs333]

SSHFS supports this with -o direct_io, but bindfs doesn't seem to support this: fuse: unknown option(s): -o direct_io`

[DUOLabs333]

ptfs works, but it is linked against fuse2. However, --forward-odirect doesn't seem to do anything.

[DUOLabs333]

You have to set int direct_io; then fi->direct_io=1;

[mpartel]

Thanks! I'll try to find time to take a proper look and add -o direct_io soon.

[DUOLabs333]

Here's something I have that works:

diff --git a/src/bindfs.c b/src/bindfs.c
index bc24154..1329ada 100644
--- a/src/bindfs.c
+++ b/src/bindfs.c
@@ -203,6 +203,8 @@ static struct Settings {
 #ifdef __linux__
     int forward_odirect;
     size_t odirect_alignment;
+    
+    int direct_io;
 #endif
 
     uid_t uid_offset;
@@ -689,6 +691,10 @@ static void *bindfs_init()
     cfg->entry_timeout = 0;
     cfg->attr_timeout = 0;
     cfg->negative_timeout = 0;
+    
+    if (settings.direct_io)
+       cfg->direct_io=1;
+
     #endif
 
     assert(settings.permchain != NULL);
@@ -706,7 +712,7 @@ static void *bindfs_init()
         bindfs_init_failed = true;
         fuse_exit(fuse_get_context()->fuse);
     }
-
+    
     return NULL;
 }
 
@@ -1252,6 +1258,7 @@ static int bindfs_create(const char *path, mode_t mode, struct fuse_file_info *f
     if (!settings.forward_odirect) {
         flags &= ~O_DIRECT;
     }
+    
 #endif
 
     fd = open(real_path, flags, mode & 0777);
@@ -1282,6 +1289,7 @@ static int bindfs_open(const char *path, struct fuse_file_info *fi)
     if (!settings.forward_odirect) {
         flags &= ~O_DIRECT;
     }
+    
 #endif
 
     fd = open(real_path, flags);
@@ -1790,7 +1798,8 @@ enum OptionKey {
     OPTKEY_ENABLE_IOCTL,
     OPTKEY_HIDE_HARD_LINKS,
     OPTKEY_RESOLVE_SYMLINKS,
-    OPTKEY_BLOCK_DEVICES_AS_FILES
+    OPTKEY_BLOCK_DEVICES_AS_FILES,
+    OPTKEY_DIRECT_IO
 };
 
 static int process_option(void *data, const char *arg, int key,
@@ -1898,7 +1907,9 @@ static int process_option(void *data, const char *arg, int key,
     case OPTKEY_BLOCK_DEVICES_AS_FILES:
         settings.block_devices_as_files = 1;
         return 0;
-
+    case OPTKEY_DIRECT_IO:
+        settings.direct_io=1;
+        return 0;
     case OPTKEY_NONOPTION:
         if (!settings.mntsrc) {
             if (strncmp(arg, "/proc/", strlen("/proc/")) == 0) {
@@ -2388,6 +2399,7 @@ int main(int argc, char *argv[])
 
         OPT2("--delete-deny", "delete-deny", OPTKEY_DELETE_DENY),
         OPT2("--rename-deny", "rename-deny", OPTKEY_RENAME_DENY),
+        OPT2("--direct_io","direct_io",OPTKEY_DIRECT_IO),
 
         OPT2("--hide-hard-links", "hide-hard-links", OPTKEY_HIDE_HARD_LINKS),
         OPT2("--resolve-symlinks", "resolve-symlinks", OPTKEY_RESOLVE_SYMLINKS),
@@ -2455,6 +2467,8 @@ int main(int argc, char *argv[])
 #ifdef __linux__
     settings.forward_odirect = 0;
     settings.odirect_alignment = 0;
+    
+    settings.direct_io = 0;
 #endif
 
     atexit(&atexit_func);

[DUOLabs333]

Another, more serious issue: bindfs modifies /proc/self/exe such that it points to /usr/bin/bindfs, instead of whatever binary is accessing it.

[mpartel]

Thanks, for the patch! Applied with minor modifications and --direct_io -> --direct-io for consistency.

/proc/self works that way because it's the bindfs process that's reading the underlying proc. It'd need to be special-cased.

[mpartel]

^ actually, opted to make direct_io the default.

[DUOLabs333]

Actually, you should not make this the default --- it will break mmap calls.

[DUOLabs333]

As a note, a maintainer on FUSE does plan on working on making direct_io work with mmap -- https://github.com/rpodgorny/unionfs-fuse/pull/117#issuecomment-1086170305.

[mpartel]

Good to know, thanks!