Request and Idea for including a tmpfs-setup package?

Development
1

This idea was inspired by this users post:

Questions regarding use of tmpfs formatting and conflicts

Summery of idea in a nutshell is basically to make the package set /tmp mount point to tmpfs and add a /etc/profile.d/ drop in to set the XDG_CACHE_HOME=/tmp/.cache variable for all users shell.

Idea for /etc/profile.d/xdg-cache.sh

#!/bin/sh

## Set XDG_CACHE_HOME to a per-user cache directory.
#   Prefer a private sub-directory under /tmp when /tmp is a tmpfs.
#   Fall back to ${HOME}/.cache if /tmp is not a tmpfs.
#
## Detect whether /tmp is a mount point (i.e. a separate filesystem).
#    On most modern distros this will be a tmpfs, but on some it may
#    be a regular disk partition.
if grep -q "^tmpfs.*/tmp.*tmpfs" /proc/mounts || mountpoint -q /tmp; then

    # /tmp is a mount point - assume it is a tmpfs.
    BASE_ROOT="/tmp/${USER}"
else
    # /tmp is part of the root filesystem (disk based).
    # Use the traditional default users /home based cache location instead.
    BASE_ROOT="${HOME}"
fi

## Build the final cache directory path.
#    We always put the cache in a ".cache" sub-folder so that tools
#    that follow the XDG spec find what they expect.
CACHE_DIR="${BASE_ROOT}/.cache"

## Ensure the directory exists and is private to the user.
#    /tmp is world-writable (drwxrwxrwt), so we must create a
#    private subtree and lock it down with chmod 700.
#
# Create the parent directory (only needed when we are using /tmp)
if [ "${BASE_ROOT}" != "${HOME}" ] && [ ! -d "${BASE_ROOT}" ]; then
    mkdir -p "${BASE_ROOT}"
    chmod 700 "${BASE_ROOT}"          
fi

# Now create the .cache directory itself
mkdir -p "${CACHE_DIR}"
chmod 700 "${CACHE_DIR}"

## Export the variable so the rest of the session sees it.
export XDG_CACHE_HOME="${CACHE_DIR}"

For the above To make it more bullet‑proof, you could tighten the /tmp detection for the export XDG_CAHCE_HOME="/tmp/${USER}/.cache creation

Systemd can generate a tmpfs mount for /tmp via the tmp.mount unit, but that unit is optional and can be disabled.
In live environments, the initramfs (often via dracut in Kicksecure case) typically mounts tmpfs at /tmp automatically.
Either the package should detect this and not interfere. otherwise a more robust way would be to ship /etc/fstab to be mounted to tmpfs by enabling and masking the builtin systemd unit, completely bypassing the need to fiddle with /etc/fstab. This is via enabling systemd’s tmp.mount unless it interferes with grub-live?

Package Structure Summary Idea

tmpfs-setup package/
├── DEBIAN/
│   ├── control
│   ├── postinst
|   └── prerm (depending on implementation)
├── etc/
│   ├── default/
│   │   └── tmpfs-config
│   └── profile.d/
│       └── xdg-cache-home.sh
└── usr/
    └── share/doc/your-package/
        └── README.Debian

Would this be a good idea to implement or do you think its a waste of time since grub-live “Live Mode” already exists and it could complicate its implementation or conflict with it with complexity?

fedoraproject . org/wiki/Features/tmp-on-tmpfs

Solaris has been doing this since 1994. (Much like other Unixes, too.) Debian’s next release defaults to tmpfs on /tmp, too. ArchLinux defaults to this as well. Ubuntu has plans for their 12.10 release.

www . debian. org/releases/trixie/release-notes/issues.en.html#the-temporary-files-directory-tmp-is-now-stored-in-a-tmpfs

From trixie, the default is for the /tmp/ directory to be stored in memory using a tmpfs(5) filesystem. This should make applications using temporary files faster, but if you put large files there, you may run out of memory.

2

Exactly. It’s a feature “in the middle” between persistent mode and live mode.

We cannot maintain that. There are way too many features and too little (none) automated testing.

Note:

3

Is there some type of wrapper that could be added so you could launch ./applications in some kind overlayroot in tmp based RAM?
This seems like a good work around between wanting “Live Mode” vs mounting all .cache in TMPFS.

Use case = user wants to start a app in RAM but doesn’t want all their RAM resources being used for “Live Mode”.

Two Examples would be generating a bitcoin wallet with Electrum in RAM so that nothing is saved. The other would be generating GPG keys so one could export their private keys without saving them to the system.

4

Um…last I checked bwrap has bwrap --tmpfs but requires more arguments or flags to do this correctly. This could be a good starting point if you where to make a bwrap wrapper for this.

bwrap \
  --unshare-all \
  --die-with-parent \
  --proc /proc \
  --dev /dev \
  --tmpfs /tmp \
  --tmpfs /run \
  --tmpfs /home \
  --tmpfs /root \
  --tmpfs /var/tmp \
  --tmpfs /var/cache \
  --tmpfs /var/lib \
  --setenv HOME /home/user \
  --setenv XDG_CACHE_HOME /home/user/.cache \
  --setenv XDG_CONFIG_HOME /home/user/.config \

The problem I see among others would be creating logic to detect the needed runtime dependencies to have exposed to bwrap. --ro-bind /usr /usr might help with automatic with having to know which libs are required. The other issue I could think of is if the application needs internet access and access to ca-certificates and ssl. Thoughts on using bwrap for a wrapper for launching apps in RAM?

5

I’m currently trying to do something like this so I thought I would put it here as a reference note for anyone interested in looking into it:

#!/usr/bin/env bash
# Isolate apps in RAM with bwrap
set -euo pipefail

# Base namespace isolation
exec bwrap \
  --unshare-all \
  --die-with-parent \
  --proc /proc \
  --dev /dev \
  \
# Read-only system tree
  --ro-bind /usr /usr \
  --ro-bind /lib /lib \
  --ro-bind /lib64 /lib64 \
  --ro-bind /etc /etc \
  \
# Fonts (optional)
  --ro-bind-try /usr/share/fonts /usr/share/fonts \
  \
# Essential RAM filesystems (No HOME subdir overlays)
  --tmpfs /tmp \
  --tmpfs /var/tmp \
  --tmpfs /run \
  --tmpfs /home/user \
  \
# Home directory
  --bind "$HOME" /home/user \
  --setenv HOME /home/user \
  --setenv XDG_CACHE_HOME /home/user/.cache \
  --setenv XDG_CONFIG_HOME /home/user/.config \
  --setenv XDG_DATA_HOME /home/user/.local/share \
  --setenv XDG_STATE_HOME /home/user/.local/state \
  \
# Network + Tor (Tor control socket no env vars needed to avoid tor over tor)
  --share-net \
  --ro-bind-try /etc/ssl/certs /etc/ssl/certs \
  --bind-try /var/run/tor/control /var/run/tor/control \
  \
# Wayland Display
  $( [ -n "${WAYLAND_DISPLAY:-}" ] && \
     echo "--bind /run/user/$UID /run/user/$UID \
           --setenv WAYLAND_DISPLAY $WAYLAND_DISPLAY \
           --setenv XDG_RUNTIME_DIR /run/user/$UID" ) \
  \
# X11
  #$( [ -n "${DISPLAY:-}" ] && \
  #   echo "--ro-bind /tmp/.X11-unix /tmp/.X11-unix \
  #         --setenv DISPLAY $DISPLAY" ) \
  #\
# Audio (pulse audio)
  $( [ -S "${XDG_RUNTIME_DIR:-}/pulse/native" ] && \
     echo "--bind $XDG_RUNTIME_DIR/pulse $XDG_RUNTIME_DIR/pulse" ) \
  \
# D-Bus
  $( [ -S "${XDG_RUNTIME_DIR:-}/bus" ] && \
     echo "--bind $XDG_RUNTIME_DIR/bus $XDG_RUNTIME_DIR/bus" ) \
  \
# GPU + Shared Memory
  $( [ -d /dev/dri ] && echo "--dev-bind /dev/dri /dev/dri 0 666" ) \
  --dev-bind /dev/shm /dev/shm \
  \
# Hand over execution to the program passed
  -- "$@"

The display handoff is what I’m having issues with since I think apps that dont fully support wayland use xwayland?