Tagged “patch”

mplayer mit Compiz betreiben

Published by cybso on

This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.

Vor einiger Zeit hatte ich vor, als Fenstermanager konsequent auf Compiz zu setzen. Leider scheiterte dieser Plan bisher vor allem an zwei inkompatiblen Programmen:

  1. OpenOffice.org Impress, die freie PowerPoint-Alternative: im Präsentationsmodus wird das Panel, also die Taskleiste, über der Folie angezeigt.
  2. mplayer, der beliebte Video-Allesfresser: das Bild flackert stark, hin und wieder stürzt der auch einfach ab

Gegen 1) habe ich noch kein Mittel gefunden, außer, für eine Präsentation auf den XFCE-Fenstermanager xfwm4 umzuschalten. Kann ich mit leben, da die wenigsten Beamer mit der von meinem Laptop bevorzugten Auflösung von 1400x1050 Pixeln problemlos zurechtkommen und ich daher sowieso die Einstellungen ändern muss.

Problem 2) ist dagegen sehr ärgerlich. Das Flackern hängt mit der Technik zusammen, die der bevorzugte und (zumindest bei mir) performanteste Video-Ausgabetreiber 'xv' nutzt. Sie verursacht Konflikte mit den Methoden, die Compiz einsetzt, um die Fenster zu rendern. Das Problem ist schon länger bekannt, aber der allgemeine Workaround war bisher, einen alternativen Ausgabetreiber wie 'x11' zu nutzen und den (nicht von 'x11' unterstützten) Vollbildmodus durch die Software rendern zu lassen:

mplayer -vo x11 -zoom -fs video.mpg

Keine schöne Lösung, da die Vergrößerung durch die Software aufwendig ist und das Video daher oftmals ruckelt. Heute bin ich durch Zufall auf einen Artikel in SmSpillaz' Blog gestoßen, welcher den von David Reveman geschriebenen mplayer-xv-Patch mplayrepatch.patch beschreibt. Dieser behebt das Problem, indem es (vereinfacht gesagt) die problematischen Aufrufe nicht an die Grafikkarte, sondern an Compiz übergibt.

Ich war ein bisschen skeptisch, aber tatsächlich, es funktioniert und ich stelle keine fühlbaren Performanzeinbußen fest. Und es klappt auch, wenn Compiz mal nicht aktiv ist. Für Gentoo-User habe ich den Patch in die aktuelleste stabile Version (1.0_rc2_p26753-r1) des mplayer-ebuilds eingebaut. Einfach die Datei mplayer-mplayrepatch-ebuild.zip in das lokale Portage-Overlay entpacken und mplayer neu kompilieren (sorry für die ZIP-Datei, tgz wurde von der Wordpress-Installation hier nicht akzeptiert).

syndaemon endlich mit einstellbarem Polling-Intervall

Published by cybso on

This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.

Nachdem ich im April einen Bug-Report zum Synaptics-Ebuild erstellt habe, ist endlich ein entsprechender Patch von Florian Schäfer auch in das Gentoo-Portage eingeflossen (ab Version 0.14.6-r3, derzeit noch mit Keyword maskiert).

Kurz zusammengefasst: Der im Paket x11-drivers/synaptics enthaltene syndaemon überwacht die Tastatur und schaltet beim Drücken einer Taste das Touchpad vorrübergehend ab. Das soll verhindern, dass man versehentlich mit dem Handballen ein anderes Fenster aktiviert und der Text nicht dort ankommt, wo er hin sollte (im schlimmsten Fall verschickt man so ein Passwort per Instant Messanger). Das Problem ist, dass diese Abfragen in sehr, sehr kurzen Abständen erfolgen - alle 20ms. Das hindert die CPU bei Notebooks daran, in den Schlafmodus zu gehen, mit dem sie normalerweise Energieverbrauch und Abwärme reduziert (hat nichts mit dem Schlafmodus des Betriebssystem oder des Monitors zu tun - bei der CPU bemerkt man diesen Modus in der Regel garnicht, da sie bei Bedarf sehr schnell wieder auf volle Leistung geht). Beobachten kann man dies zum Beispiel mit dem von Intel entwickelten Kommandozeilen-Programm "PowerTop". Im Ergebnis bedeutet das schlicht und einfach eine geringere Akkulaufzeit.

Der neue Patch fügt einen Kommandozeilenparameter hinzu, mit dem das Abfrage-Intervall konfiguriert werden kann. Der Aufruf "syndaemon -m 500" reduziert dieses zum Beispiel auf 500ms, was für den normal schnellen Menschen immer noch ausreichend sein sollte. Wer XFCE benutzt, kann diesen Befehl zum Beispiel in eine ausführbare Datei im Verzeichnis '~/.config/autostart' ablegen, KDE-Benutzer schauen unter '.kde/Autostart' nach und Gnome... naja, weiß ich gerade auch nicht :-) Für diejenigen, welche sich ihren XFCE-Desktop nach meinem Vorbild verschlankt haben, habe ich inzwischen eine bessere .xinitrc geschrieben, die das Verzeichnis '.config/autostart' auswertet und alle ausführbaren Dateien startet.

Übrigens: Ich bin im Portage *g*!

30 Jul 2008; Samuli Suominen +files/synaptics-0.14.6-configurable_polling_interval.patch, +synaptics-0.14.6-r3.ebuild: Apply configurable polling interval patch from Novell so that syndaemon doesn't wake up CPU so often. Bug 216679, thanks to Roland Tapken, Thomas Kirchner and Krister Bäckman.

cpufreqd: select rule depending on external command

Published by cybso on

This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.

Cpu Frequency Daemon is a very configurable program for throttling the cpu's frequency depending on "rules". A rule tests for battery state, cpu temperatur, active processes and so on.

For example, a rule which throttles your cpu when it's to hot might look like this:

[Rule]
name=CPU Too Hot
acpi_temperature=65-100
cpu_interval=50-100
profile=Performance Low
[/Rule]

And if you want full performance when watching movies you might have a rule like this:

[Rule]
name=Movie Watcher
programs=xine,mplayer,gmplayer
battery_interval=0-100
acpi_temperature=0-60
profile=Performance High
[/Rule]

(For more examples, have a look at the manpage)

As a Gentoo user I want full cpu power when emerge is running. But sadly, "programs=emerge" won't work because emerge' process actually is the python interpreter (and surely you don't want to define "programs=python" as it would fire on your processor for all python scripts):

$ ps a | grep emerge
13423 pts/2    SN+    0:02 /usr/bin/python -O /usr/bin/emerge libc

So what we need is a cpufreqd.conf-statement which executes a shell command and scores the rule depending on the process' exit code (0 is good and anything else is bad). There is already a plugin, "exec", which executes a command before and after testing a rule or switching the profile, although this is not exactly what we want. Nevertheless the code of this plugin (cpufreqd_exec.c) only needs a few changes to get a new options called "exec" which does exactly what we need (I've attached patches for cpufreqd-2.2.1 and cpufreqd-2.3.3).

The rule for switching to "Performance High" when emerge is running now looks like this:

[Rule]
name=emerge is running
exec=ps -u root | grep emerge
battery_interval=0-100
acpi_temperature=0-65
cpu_interval=0-100
profile=Performance High
[/Rule]

(If somebody knows an more efficient method to check wether emerge is running or not, please post it into the comments).

X.Org, evdev und HAL - Teil 3

Published by cybso on

This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.

Technobabble-Warnung

Eigentlich dachte ich, das Problem aus dem Zusammenspiel von X11, Multimedia-Tastatur, evdev-Treiber, HAL und LinEAK sei gelöst gewesen - doch hat "roo" mich in den Kommentaren darauf aufmerksam gemacht, dass mit dem xorg.conf-Schalter “AutoAddDevices = no" einfach nur HAL deaktiviert wurde. Das funktioniert zwar, ist aber nicht das, was man gerne haben möchte - nämlich die Verwaltung aller Eingabegeräte an einer zentralen Stelle, im "Hardware Abstraction Layer".

Nun hat "roo" am Dienstag einen weiteren Kommentar geschrieben, den ich jedoch übersehen habe:

Also ich hab herausgefunden, dass das Problem nicht bei HAL, nicht bei evdev und auch nicht bei X liegt. Sondern beim Desktop Environment - sprich Gnome/Xfce/KDE. Habe nämlich mal Fluxbox emerged und damit mal probiert (Fluxbox lässt sich ja fix emergen und starten). Und dort habe ich diese Probleme nicht. Alle Tasten werden von xev perfekt erkannt. Und verursachen keine Probleme.

Tatsächlich hatte ich auch schon eigene Experimente durchgeführt, und bin zu dem gleichen Ergebnis gekommen: Unter Fluxbox kann ich alle Tastencodes der Spezialtasten mit xev beobachten, unter XFCE jedoch nicht die Lautstärketasten - und ausgerechnet die hatte ich in meinem letzten Beitrag meistens zum Testen verwendet.

In der Ausgabe von xev sind mir dann jedoch einige Details aufgefallen (hier als Beispiel für die Taste "Startseite"):

(continue reading)

Erstes Hardcore-Debugging

Published by cybso on

This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.

Update: Due to an increasing number of english speaking visitors I have translated the main conclusion of this entry. Have a look at the comments.

Na, das ging ja gut los. Der Versuch, mit dem KNetworkManager eine statische IP-Adresse über's normale Kabel einzurichten, scheiterte. Die Daten wurden akzeptiert, aber nicht aktiviert. Der gleiche Versuch mit der Gnome-Variante des Tools ( nm-applet) verlief erfolgreich, integrierte sich aber natürlich alles andere als gut in die KDE-Umgebung (ansonsten hätte ich damit auch leben können).

Auf der Kommandozeile war als Ausgabe nur diese läppische Zeile zu finden:

Activate Connection /org/freedesktop/NetworkManagerSettings/Connection/2 on Device /org/freedesktop/Hal/devices/net_00_00_f1_7b_97_e0

Das Syslog ( /var/log/syslog) war da etwas informativer:

Nov 3 14:02:40 sam NetworkManager: connection _get _settings _cb(): connection _get _settings _cb: Invalid connection: 'NMSettingIP4Config' / 'addresses' invalid: 1
Nov 3 14:02:40 sam NetworkManager: connection _get _settings _cb(): connection _get _settings _cb: Invalid connection: 'NMSettingIP4Config' / 'addresses' invalid: 1
Nov 3 14:02:57 sam NetworkManager: connection _updated _cb: assertion `old _connection != NULL' failed

Bei der Suche nach dieser Ausgabe stieß ich auf einen Bugreport, der mir zeigte, dass ich nicht der einzige mit dem Fehler war. Um es kurz zu machen: Nachdem es auch dort keine Lösung gab, habe ich mir die Quelltexte der Pakete network-manager und network-manager-kde heruntergeladen, mit einigen Debugging-Ausgaben angereichert und bin schließlich dahinter gekommen, dass der Systemdienst NetworkManager die Netmask im CIDR-Format erwartet ("/24"), KNetworkManager diese aber im Dezimalformat ("255.255.255.0") übergibt.

Zu einem Patch hatte ich dann keine Zeit mehr, aber es gibt einen einfachen Workaround: Im Feld für die Netzmaske diese in CIDR-Schreibweise in den ersten Block eintragen, und die restlichen mit Nullen auffüllen: "24.0.0.0". Dann bekommt NetworkManager genau das übergeben, was er erwartet.

Aber das so ein fundamentaler Fehler im Release noch nicht behoben worden ist, erstaunt mich dann ja doch.

Flexbackup: Read per-directory exclude expressions from files

Published by cybso on

This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.

Today I wrote a patch to Flexbackup 1.2.1 which allows you to define exclude expressions on a per-directory-base (like svn:ignore, cvs_ignore or tar's --exclude-from). Apply this patch and add the following line to your flexbackup.conf:

$exclude_expr_filename = '.flexbackup_exclude';

This activates an additional routine in the file_list_cmd() method. As soon as the 'find' command has enough parameters to iterate through all directory it is used to retrieve a list of '.flexbackup_exclude' files. Each file is read line by line and a regular expression will build and appended to the directory's name, e.g:

$ cat dummy/.flexbackup_exclude
.*\.tmp$
a_very_big_file\.iso

Will result in the expression:

dummy\/((.*\.tmp$)|(a_very_big_file\.iso))

All files matching this expression will be ignored. This is done by piping find's output through xargs and perl:

$ find . [conditions...] -print0 | xargs -0 perl -e 'foreach (@ARGV) { print "$_" if ! /dummy\/((.*\.tmp$)|(a_very_big_file\.iso))/ and 1'

If more than one .flexbackup_exclude-file is found more conditions are prepended to the 'and 1'-dummy-condition. Because every condition is tested (and ignored if compilation failed) it should not be possible to break the backup using these files.

Download: flexbackup-exclude-expressions.patch

PS: Perl sucks ;)

suphp: distinguish between script owner and process owner

Published by cybso on

This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.

This is a re-post of my mail to the suphp mailing list. Although the behaviour described here is a serious design issue, I've never got any feedback.

The attached patch is some kind of "proof of concept" to solve a security related problem I have with suPHP.

Problem: Run script with file/directory owner threatens the user's files.

suPHP is intended to run a PHP script using a specific process owner. When configured in "owner" or "paranoid" mode this always will be the owner of the file, but in any case it will be executed having the same owner as the parent directory (if it isn't owned by root).

This can be (and I think in most cases is) used in multihosting environments to prohibit the users from reading other user's files on an operating system level.

But there is a big security problem with this solution. Not only an exploitable PHP script can modify itself, but it is also possible for an attacker to compromise the user's configuration files. E.g. a bad guy could place a key logger in the user's .profile file. Or even simpler, fake a failed login to retrieve the user's password.

A solution can be to execute the PHP process only with the user's group and a restricted "nobody" user. Sadly, suPHP wouldn't allow the script to be executed if it and it's parent directory are not owned by the nobody user. Not a very satisfying situation if you need the system administator's help to modify your site.

My suggestion is to distinct between the user/group the script is executed with and the user/group the script have to be owned by. The attached patch (quick&dirty, only for apache2) add's an optional third parameter "processUser" to suPHP_UserGroup and a new environment variable SUPHP_PROCESS_USER, but maybe a new configuration directive named "suPHP_ScriptOwner" is preferable. Ownership checks are done using targetUser, permission change is done using processUser. If empty, processUser = targetUser.

This way you even can ensure that a php file created by suPHP (e.g. because of a file upload with .php extension into a public directory or an exploitable call to file_put_contents()) would never be executed - because it is owned by processOwner where it should be owned by targetUser!