tmpfs statt /tmp ?

[tommbutu]

kann man das tmp verzeichnis problemlos durch ein tmpfs dir ersetzen, oder ist das bedenklich (sicherheit/performance) ?

ich hab nur 2 partitionen will aber /tmp noexec mounten. gibt es vielleicht noch einen anderen weg?

[Roger Wilco]

kann man das tmp verzeichnis problemlos durch ein tmpfs dir ersetzen, oder ist das bedenklich (sicherheit/performance) ?

Ja, geht problemlos.

gibt es vielleicht noch einen anderen weg?

Ein Loopfile.

[tommbutu]

kannst du bitte beschreiben wie es mit einem loopfile gelösst werden kann? hab dazu nichts gefunden mittels google

[flo]

man mount sagt dazu:

Code: Select all

THE LOOP DEVICE
       One further possible type is a mount via the loop device. For example, the command

         mount /tmp/fdimage /mnt -t msdos -o loop=/dev/loop3,blocksize=1024

       will set up the loop device /dev/loop3 to correspond to the file /tmp/fdimage, and then mount this device on /mnt.

       This type of mount knows about three options, namely loop, offset and encryption, that are really options to losetup(8).  If the mount requires a passphrase, you will  be  prompted
       for one unless you specify a file descriptor to read from instead with the --pass-fd option.  (These options can be used in addition to those specific to the filesystem type.)

       If  no  explicit loop device is mentioned (but just an option `-o loop' is given), then mount will try to find some unused loop device and use that.  If you are not so unwise as to
       make /etc/mtab a symbolic link to /proc/mounts then any loop device allocated by mount will be freed by umount.  You can also free a loop device by hand, using  `losetup  -d',  see
       losetup(8).

Die Loop-Devices müssen gegebenenfalls noch im Kernel aktiviert werden, bin aber vom Loop auch weg und nehme jetzt tmpfs.

flo.

[tommbutu]

ok bevor ich reboote hier nochmal verifizieren bitte.

cd /var/spool
dd if=/dev/zero of=tmp1 bs=1024 count=800000
mke2fs -j tmp1
mount -o loop,rw,nodev,nouser,noexec,nosuid /var/spool/tmp1 /tmp

jetzt in fstab

/var/spool/tmp1 /tmp ext3 loop,rw,nodev,nouser,noexec,nosuid 0 0

---------------

problem ist im moment das ich beim starten von mysql die meldung bekomme

Starting MySQL database server: mysqld...failed.
Please take a look at the syslog.
/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)'
Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!

mysqld.sock existiert im angegebenen directory. muss also irgendwie jetzt mit dem neuen mounten des tmp zusammenhängen.

EDIT:

syslog meldet das ein tmp file in /tmp nicht erstellt werden konnte. /tmp ist 755 gemoutet und gehört natürlich root

[captaincrunch]

/tmp ist 755 gemoutet und gehört natürlich root

Probier's mal mit 1777.

[tommbutu]

selber fehler

mysqld[8314]: ^G/usr/sbin/mysqld: Can't create/write to file '/tmp/ibu8kITO' (Errcode: 13)

nachdem ich die fstab editiert habe...muss ich da nochmal restarten damit mysql das versteht? eigentlich müsste nach dem mount befehl mount -o loop,rw,nodev,nouser,noexec,nosuid /var/spool/tmp1 /tmp doch alles seinen gewohnten gang gehen :?:

[flo]

Das Booten brauchst Du nicht unbedingt

Code: Select all

mount -a

wenn er hier nicht meckert, ist in der Regel auch die fstab o.k.

Gib doch mal die Permission vom /tmp und die Ausgabe von "mount" rüber - eventuell ist da noch ein Fehler drin.

flo.

[tommbutu]

hab ein reboot hinter mir und nun scheint es zu funktionieren.

EDIT:

@flo

jip genau dieses mount -a hatte ich noch irgendwo im hinterkopf...aber ist mir nicht mehr eingefallen :)

@christian

wieso sticky und 777? alle rechte für group und other ist das so gut bei tmp...ich denk mal nicht...default sind doch 755, oder ?

[tommbutu]

zu früh gefreut :?

mount -o loop,rw,noexec,nodev,nouser,nosuid,errors=continue /var/spool/tmpFile /tmp

meldet nichts

mount -a meldet auch nichts

/tmp ist mittlerweile 1777 war aber auch schon 755. mysql meldet immernoch in syslog das kein temp file in /tmp erstellt oder geschrieben werden konnte (siehe error von oben)

@flo

wie hast du denn tmpfs eingerichtet? vielleicht liegt ja dort irgendwo der fehler. am ext3 kann es nicht liegen oder ?

[flo]

Code: Select all

none            /tmp    tmpfs   size=100M,nodev,noexec,nosuid   0       0

Das mit dem tpfs war ein Tipp vom Captain, wenn ich das richtig in Erinnerung habe - der Vorteil vom Image per Loop war die feste Größe. Nachdem der Captain mich allerdings darauf hingewiesen hat, daß man die Size beim mounten definieren kann, hab ichs ausprobiert und seitdem am Laufen.

flo.

[captaincrunch]

wieso sticky und 777? alle rechte für group und other ist das so gut bei tmp...ich denk mal nicht...default sind doch 755, oder ?

Das Sticky-Bit dient ja gerade dazu, dass nur der Owner das File löschen kann, und da nun halt mal jeder in /tmp reinschreiben können sollte (bzw. muss), passt die Sache mit den 1777. qed

[isotopp]

@christian

wieso sticky und 777? alle rechte für group und other ist das so gut bei tmp...ich denk mal nicht...default sind doch 755, oder ?

Nein, Default fuer /tmp ist 1777.

Das /tmp muß für alle UID und GID beschreibbar und lesbar sein. Durch das Sticky-Bit stellst Du sicher, daß nur der Eigentümer einer Datei diese löschen kann.

Programmme, die Dateien in /tmp anlegen wollen, sollten ein Verzeichnis /tmp/<username> mit 0700 erzeugen (das darf fehlschlagen=, dann sicherstellen, daß das /tmp/<username> auch ein Verzeichnis ist und es auch <username> gehört und 0700 ist, und dann darin die gewünschten Dateien erzeugen. Das Verzeichnis kann danach stehen bleiben.

[Joe User]

Code: Select all

tmpfs  /tmp  tmpfs  mode=1777,size=100M,nodev,noexec,nosuid  0 0

mount -t tmpfs -o mode=1777,size=100M,nodev,noexec,nosuid /tmp

[tommbutu]

ok damit kann man arbeiten. also mit dem fstab eintrag

tmpfs /tmp tmpfs mode=1777,size=100M,nodev,noexec,nosuid 0 0

erstellt das system einen 100MB speicherplatz...im ram speicher(?) und reserviert den für /tmp. die variante die ich oben beschrieben habe verwendet dafür eine tmpdatei die dann als /tmp über loopback gemountet wird...richtig?

wofür ist das:

mount -t tmpfs -o mode=1777,size=100M,nodev,noexec,nosuid /tmp

beim ausführen bekomm ich die usage von mount angezeigt. fehlt da nicht irgendwie das "was" nach /tmp gemountet wird?

------------------------------------

ich hatte im tutorial gelesen das zusätzlich /dev/shm (shared memory nehm ich mal an) abgesichert werden sollte

While we are at it we are going to secure /dev/shm. Look for the mount line for /dev/shm and change it to the following:
none /dev/shm tmpfs noexec,nosuid 0

das kommt hier aber auch nicht in frage oder? der befehl mount zeigt zwar tmpfs on /dev/shm type tmpfs (rw) aber das kann ich wohl nicht beeinflussen, oder?

[Joe User]

http://www-128.ibm.com/developerworks/l ... l-fs3.html

[tommbutu]

weiss noch jemand wie ich debian umstricken muss damit apt-get keine probleme mehr macht?

Auf Debian-Systemen ist noch etwas mehr Arbeit nötig, da dpkg auf /tmp zurückgreift, um die Pre-Installation von Packeten durchzuführen. Dazu erstellt man /etc/apt/apt.conf.d/50tmp mit folgenden Inhalt:

DPkg::Pre-Install-Pkgs {"mount -o remount,exec /tmp";};
DPkg::Post-Invoke {"mount -o remount /tmp";};

reicht die lösung? oder funktioniert das mit tmpfs /tmp tmpfs mode=1777,size=100M,nodev,noexec,nosuid 0 0 nicht mehr?

[Joe User]

Beim umount eines tmpfs gehen die darin abgelegten Daten verloren, wenn Debian dieses nicht berücksichtigt hat...

[tommbutu]

das müsste doch eigentlich passen...es wird ja nur ein pre-install ausgeführt. tmp wird neu gemountet (exec) pre-install wird ausgeführt und anschliessend wird der alte noexec wieder gesetzt.

ich hoffe einfach mal das es so klappt. wenn jemand einen besseren vorschlag hat, kann er ja mal posten.

bis denne

[flo]

nee, das ist schon o.k. - ich mache genau das händisch und die Installationen laufen dann durch.

flo.

[Joe User]

Das Problem mit dem Datenverlust betrifft ja nicht apt, sondern Software, welche vor dem umount Daten im /tmp abgelegt hat (z.B. PHP-Sessions, Sockets, etc...) und nach dem umount auf die verlorenen Daten zugreifen will/muss...

[tommbutu]

ist das bei allen verfahren mit tmpfs so? wie sieht es mit dem tmpfs File verfahren was ich weit oben genannt habe aus...würde tmp da auch immer geleert beim remount? wenn nicht arbeite ich in der richtung nochmal weiter. es läuft halt ein lamp und da ist ja nicht auszuschliessen das da mal eine php session rein muss usw

sorry ich konnte den ibm text noch nicht durchlesen...wenns drin steht lese ich den später mal