virtme: propagate /proc/sys/fs/nr_open from host to the guest

Some distro, such as Fedora or CachyOS, are using a higher limit of max
open files, beyond the kernel default. Consequently, some applications
may expect to operate under this increased limit and, as a result, we
may hit EPERM errors in the virtme-ng guest.

Example:

 $ sudo su -
 sudo: pam_open_session: Permission denied
 sudo: policy plugin failed session initialization

 # strace -f -e prlimit64,setrlimit sudo /bin/true
 ...
 prlimit64(0, RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=2048*1024}, NULL) = -1 EPERM (Operation not permitted)
 ...
 # cat /proc/sys/fs/nr_open
 1048576

Fix this by propagating the value from /proc/sys/fs/nr_open from the
host to the vng guest.

This fixes one of the issues reported in #75.

Signed-off-by: Andrea Righi <[email protected]>

virtme/commands/run.py

@@ -826,6 +826,13 @@ def do_it() -> int:
             args.memory += "M"
         qemuargs.extend(["-m", args.memory])
 
+    # Propagate /proc/sys/fs/nr_open from the host to the guest, otherwise we
+    # may see some EPERM errors, because certain applications/settings may
+    # expect to be able to use a higher limit of the max number of open files.
+    with open('/proc/sys/fs/nr_open', 'r', encoding="utf-8") as file:
+        nr_open = file.readline().strip()
+        kernelargs.append(f"nr_open={nr_open}")
+
     # Parse NUMA settings.
     if args.numa:
         for i, numa in enumerate(args.numa, start=1):

virtme/guest/virtme-init

@@ -54,6 +54,11 @@ elif [[ -d "/lib/modules/$kver" ]]; then
     mount -n -t tmpfs -o ro,mode=0000 disallow_modules "/lib/modules/$kver"
 fi
 
+# Adjust max limit of open files
+if [[ -n "${nr_open}" ]]; then
+    echo ${nr_open} > /proc/sys/fs/nr_open
+fi
+
 # devtmpfs might be automounted; if not, mount it.
 if ! grep -q devtmpfs /proc/mounts; then
     # Ideally we'll use devtmpfs (but don't rely on /dev/null existing).