/tmp ordner ändern

[clue]

Ok, scheinbar komm ich wohl nicht auf die richtigen Suchbegriffe bei google, denn auch nach langem Herumgesuche bin ich nicht auf die Lösung gekommen:

Wie kann ich für meinen User xyz den /tmp Ordner ändern? Soll heißen: Wie kann ich einem spezifischen User ein spezifisches, temporäres Verzeichnis zuordnen?

Danke im Voraus

[gxyz]

Wie kann ich für meinen User xyz den /tmp Ordner ändern?

... kurze Antwort: gar nicht
(der Verzeichnisbaum ist, wenn man Sonderfälle wie chroot außer acht lässt, nicht benutzerabhängig, d.h. wenn ein Programm die Datei "/tmp/bla.fasel" öffnet, dann landet das immer im gleichen Verzeichnis ...)

Allerdings honorieren viele Programme und Bibliotheksfunktionen auch Envrironment-Variablen. Leider sind die verwendeten Namen nicht ganz einheitlich, aber wenn Du die Variablen "TMPDIR", "TEMP" und "TMP" auf das gewünschte Verzeichnis setzt (und exportierst) sollte es bei "wohlerzogenen" Programmen klappen ...

[clue]

hmm Danke! Kann man nicht irgendwie in der Bash oder einer anderen Datei das /tmp Verzeichnis vorgeben? Jedenfalls meine ich sowas mal gelesen zu haben, kanns halt nur nicht finden.

[cosmac]

hmm Danke! Kann man nicht irgendwie in der Bash oder einer anderen Datei das /tmp Verzeichnis vorgeben? Jedenfalls meine ich sowas mal gelesen zu haben, kanns halt nur nicht finden.

Das war wohl die TMPDIR-Technik, wie von gxyz beschrieben, dabei schreibt man ja sowas ähnliches in z.B. die .bashrc

Code: Alles auswählen

export TMPDIR="/das/neue/tmp"

---
Es könnte aber wirklich gehen, wozu gibt es /proc/self/mounts? So wie ich das verstehe, müsste "nur" der erste User-Process nach dem login mit clone() statt mit fork() erzeugt werden. Dabei übernimmt der zunächst den aktuellen, allgemeinen Verzeichnisbaum. Ein "mount /neues/tempdevice /tmp" ist aber nur für ihn und seine Kinder sichtbar -- fertig!

Statt login oder gdm umzubauen kann man wohl auch ein neues Programm dazwischen schalten, das genau das macht. Es werden noch Opfer Freiwillige zum Testen gesucht

[clue]

Danke, Cosmac! Das mit dem TEMPDIR werd ich dann mal ausprobieren. Dein anderer Vorschlag klingt irgendwie nicht nach dem typischen "Debian Way" .

Mir gehts vor allem um Peazip, da es, wenn ich mal größere Verzeichnisse packen will, immer die letzten, spärlichen Reste meiner Root-Party-Zone zumüllt. In den Options von Peazip gibts leider keine Möglichkeit, den /tmp Ordner zu ändern.

Ich werd Euch dann berichten.

[pferdefreund]

So das Programm "open Source" ist, einfach Quellcode anpassen und
manuell installieren - für ein Einzelprogramm sehe ich da nicht wirklich große Probleme betreffs automatischer updates usw. Außerdem kann mans ja mit checkinstall in ein .deb verwandeln.

[uname]

Mir gehts vor allem um Peazip, da es, wenn ich mal größere Verzeichnisse packen will, immer die letzten, spärlichen Reste meiner Root-Party-Zone zumüllt

Du kannst ja für /tmp ein eigenes Filesystem nutzen. Zudem kann ein normaler Benutzer nicht das Filesystem vollmüllen. Nur "root" darf bis aufs letzte Bit schreiben. Irgendwo kann man festlegen, wie viel Speicher frei bleiben muss.

[gxyz]

Es könnte aber wirklich gehen, wozu gibt es /proc/self/mounts?

... das frage ich mich allerdings auch schon lange ;-)

im Prinzip ist es seit einer Weile vorgesehen, private Namensräume für Prozesse zu ermöglichen (was an sich für manche Zwecke wich chroot-Umgebungen recht nützlich wäre). Abgesehen von Documentation/filesystems/sharedsubtree.txt in den Kernel-Sourcen scheint es darüber allerdings nicht viel an Informationen zu geben. Außerdem ist es zumindest gegenwärtig offensichtlich lediglich möglich, zu beeinflussen, was geschieht, wenn in einen per "bind"-mount an mehreren verschiedenen Stellen eingebundener Verzeichnisbaum weitere Verzeichnisbäume gemountet oder entfernt werden.

Im Allgemeinen gilt wohl immer noch, dass die gemounteten Dateisysteme global sind ...

[Methusalix]

Hallo,

Nur "root" darf bis aufs letzte Bit schreiben. Irgendwo kann man festlegen, wie viel Speicher frei bleiben muss.

Das sind die für root reservierten 5%, die meines Wissens per default sowieso immer frei bleiben. Die Größe
läßt sich aber bei Bedarf mit tune2fs runterschrauben.

Gruß M.

[cosmac]

im Prinzip ist es seit einer Weile vorgesehen, private Namensräume für Prozesse zu ermöglichen (was an sich für manche Zwecke wich chroot-Umgebungen recht nützlich wäre).

und es funktioniert tatsächlich, jedenfalls hab' ich auf die Schnelle nur eine Ungereimtheit gefunden: wenn /etc/mtab kein Link auf /proc/mounts ist, zeigen "mount" und "df" Unsinn an.

Abgesehen von Documentation/filesystems/sharedsubtree.txt in den Kernel-Sourcen scheint es darüber allerdings nicht viel an Informationen zu geben.

CLONE_NEWNS (since Linux 2.4.19)
Start the child in a new mount namespace.

Every process lives in a mount namespace. The namespace of a
process is the data (the set of mounts) describing the file
hierarchy as seen by that process. After a fork(2) or clone()
where the CLONE_NEWNS flag is not set, the child lives in the
same mount namespace as the parent. The system calls mount(2)
and umount(2) change the mount namespace of the calling process,
and hence affect all processes that live in the same namespace,
but do not affect processes in a different mount namespace.

After a clone() where the CLONE_NEWNS flag is set, the cloned
child is started in a new mount namespace, initialized with a
copy of the namespace of the parent.

Only a privileged process (one having the CAP_SYS_ADMIN capabil-
ity) may specify the CLONE_NEWNS flag. It is not permitted to
specify both CLONE_NEWNS and CLONE_FS in the same clone() call.

Im Allgemeinen gilt wohl immer noch, dass die gemounteten Dateisysteme global sind ...

Im Allgemeinen auf jeden Fall, aber eine mini-Demo löst die ursprüngliche Aufgabe schon fast. Wenn man es mit "su -c" startet, bekommt man ein xterm mit einem eigenen /tmp. Bis man es wirklich benutzen kann, kostet es noch einige Fleißarbeit, vor allem muss ein vernünftiges environment erzeugt werden.

Code: Alles auswählen

#define _GNU_SOURCE 1
#include <errno.h>
#include <libgen.h>
#include <unistd.h>
#include <sched.h>
#include <stdio.h>
#include <string.h>
#include <sys/mount.h>
#include <sys/syscall.h>

int
main (void)
{
char  *cmd = "/usr/bin/xterm";
char  *args[2];
int    scrv;

  scrv = syscall (SYS_clone, CLONE_NEWNS, NULL);
  switch (scrv) {
  case 0:
    if (mount ("newtmp", "/tmp", "tmpfs", 0, "")) {
      printf ("mount newtmp: %s\n", strerror (errno));
      return 1;
    }
    setgid (100);
    setuid (1000);
    args[0] = basename (cmd);
    args[1] = NULL;
    execv (cmd, args);
    printf ("execv %s: %s\n", args[0], strerror (errno));
    return 1;
  case -1:
    printf ("clone: %s\n", strerror (errno));
    return 1;
  default:
    printf ("new pid: %d\n", scrv);
    break;
  }
  return 0;
}

[gxyz]

und es funktioniert tatsächlich, jedenfalls hab' ich auf die Schnelle nur eine Ungereimtheit gefunden: wenn /etc/mtab kein Link auf /proc/mounts ist, zeigen "mount" und "df" Unsinn an.

cool ;-)
Wobei mir dabei, wie schon angedeutet als Anwendung hauptsächlich chroot-Umgebungen und dgl. einfallen, und da gibt es dann ein Problem, für dass ich so trotzdem noch keine rechte Lösung sehe: Meistens braucht man, damit es klappt, innerhalb der Chroot-Umgebung auch ein "/proc"; trotz privatem Namensraum erbt das aber erst einmal die gleichen Informationen, wie das Ausgangs-Dateisystem, sprich: alles darin ist auf das "falsche" Root-Directory bezogen ...

[clue]

Du kannst ja für /tmp ein eigenes Filesystem nutzen.

Also mit export TMPDIR="/das/neue/tmp" in die .bashrc klappts nicht, das /tmp Verzeichnis zu ändern. Sowohl KDE als auch Peazip scheren sich da nicht drum.
Also bleibt Dein Ansatz. Wie kann man also für /tmp ein eigenes Filesys nutzen? Bei dieser Methode gilt es aber auch für alle anderen Nutzer mit, richtig?