UNIXwork

XNEdit Update 1.0.1

5. April 2019

Hat nicht lange gedauert, da gibt es schon ein kleines Update für XNEdit. Ein schwerer Fehler beim konvertieren von Dateikodierungen musste behoben werden. Wenn eine Datei mit einer anderen Kodierung als UTF-8 gespeichert werden sollte, wurden dabei ein paar Zeichen übersprungen.

Des Weiteren gibt es ein paar Detailverbesserungen, wenn die Locale-Encoding nicht UTF-8 ist.

XNEdit auf Sourceforge

Autor: Olaf | 0 Kommentare | Tags: xnedit, x11, unix, linux

XNEdit - Mein NEdit-Fork mit Unicode-Support

6. March 2019

NEdit dürfte einer der ältesten grafischen Texteditoren für Unix-Systeme sein. Seit 1991 reifte dieses gute Stück Software und hat über die Jahre einige Features angesammelt. Leider ist die Entwicklung in diesem Jahrtausend mehr oder weniger eingeschlafen. Bis 2004 gab es noch regelmäßig neue Releases, danach jedoch praktisch nur noch Bug-Fixes.

Vor allem wurde es verpasst, in NEdit auch Support für Unicode einzubauen, was in der heutigen Zeit aber ein absolut unverzichtbares Feature ist. Auch das X11 Core basierte Text Rendering, welches nur Bitmap-Fonts unterstützt, ist nicht mehr zeitgemäß.

Im Dezember 2018 hatte ich spontan Lust mich dieser Probleme anzunehmen und NEdit so wieder zu einem benutzbaren Editor zu machen. Das ist mir hoffentlich auch ganz gut gelungen. Mit dem neuen Xft-basiertem Textrenderer gibt es endlich Antialiasing und Unicode wird nun auch unterstützt.

Damit ist der erste Meilenstein in meinem Modernisierungsplan erreicht. Weitere Verbesserungen und neue Features sind geplant, aber jetzt veröffentliche ich das erstmal als XNEdit 1.0.

Downloads gibt es hier oder auf Sourceforge. Des Weiteren existiert das Projekt auch auf GitHub.

Autor: Olaf | 0 Kommentare | Tags: xnedit, x11, unix, linux

Unix Rechteverwaltung: setuid, setgid, sticky bit

22. April 2018

Die klassische Unix-Rechteverwaltung dürfte den meisten ein Begriff sein. Es gibt drei Arten von Zugriffsrechten: read, write und execute. Für jede Datei sind diese Rechte jeweils für den User, die Group und Other gesetzt. Macht insgesammt 9 Bits, es gibt jedoch noch drei weitere Bits, nämlich für setuid, setgid und das sticky bit. Die Bedeutung dieser zusätzlichen Rechte hängt teilweise davon ab, um was für eine Art Datei es sich handelt.

setuid

Wenn das setuid-Bit für Executables gesetzt ist, dann wird das Programm mit den Rechten des Dateieigentümers ausgeführt. Dies ist zum Beispiel nötig für su, welches Root-Rechte für seine Funkion benötigt.

setgid

Bei Executables bewirkt das setgid-Bit, ähnlich wie bei setuid, dass Programme die Gruppenrechte des Eigentümers beim Ausführen erhalten.

Das setgid-Bit kann jedoch auch für Verzeichnisse gesetzt werden. Dies bewirkt, dass Dateien, die in diesem Verzeichnis erstellt werden, die Gruppe des Verzeichnisses erhalten, und nicht die Gruppe des Benutzers, der die Datei erstellt.

Sticky Bit

Das Sticky Bit kann auf Verzeichnissen angewendet werden und bewirkt bei diesen, dass die dort enthaltenen Dateien nur von ihrem Besitzer gelöscht werden können. Dies ist sinnvoll bei Verzeichnissen, auf die mehrere Benutzer vollen Zugriff haben, denn ohne Sticky Bit kann jeder enthaltene Dateien löschen.

Beispiel: chmod und ls

Erstellen wir kurz eine Datei:

$ touch file
$ ls -l 
total 0
-rw-r--r-- 1 olaf user 0 Apr 22 12:51 file

setuid:

$ chmod u+s file
$ ls -l
total 0
-rwSr--r-- 1 olaf user 0 Apr 22 12:51 file

setgid:

$ chmod g+s file
$ ls -l
total 0
-rwSr-Sr-- 1 olaf user 0 Apr 22 12:51 file

Sticky Bit:

$ mkdir dir
$ ls -l
total 4
drwxr-xr-x 2 olaf user 4096 Apr 22 12:53 dir
-rwSr-Sr-- 1 olaf user    0 Apr 22 12:51 file
$ chmod +t dir
$ ls -l
total 4
drwxr-xr-t 2 olaf user 4096 Apr 22 12:53 dir
-rwSr-Sr-- 1 olaf user    0 Apr 22 12:51 file
Autor: Olaf | 0 Kommentare | Tags: unix

File Locking - flock vs fcntl

19. December 2017

Wer sich mit File-Locking beschäftigt, der wird vermutlich auf zwei Möglichkeiten stoßen: die Funktion flock und Locking mit fcntl. Es gibt zwei wichtige Unterschiede zwischen diesen beiden Funktionen.

Locks, die mit flock erstellt wurden, werden bei einem fork an den Kind-Prozess weitergegeben. Es wird jedoch nicht der Lock kopiert, wenn durch fork oder dup der Filedescriptor dupliziert wird, denn jeder Filedescriptor auf die gelockte Datei enthält nur eine Referenz auf den selben Lock. Der Lock bleibt bestehen bis entweder alle Filedeskriptoren geschlossen sind, oder explizit eine Unlock-Operation auf einen Filedescriptor mit diesem Lock, egal in welchem Prozess, ausgeführt wird.

Mit fcntl erstellte Locks werden bei einem fork hingegen gar nicht weitergegeben. Der Lock gilt immer nur für den Prozess, der ihn erstellt hat. Außerdem wird ein Lock entfernt, wenn auch nur ein Filedescriptor der gelockten Datei geschlossen wird.

Der andere große Unterschied ist, dass nur Locking mit fcntl Posix-spezifiziert ist. Die Funktion flock hingegen ist eine BSD-Erfindung, die jedoch auch von Linux übernommen wurde. Andere Unixe, wie z.B. Solaris, unterstützen flock gar nicht.

Außerdem unterscheidet sich auch das Interface der beiden Funktionen deutlich. Mit fcntl hat man ein bisschen mehr Schreibarbeit, dafür ist es auch möglich nur einen Bereich einer Datei zu locken, wärend flock etwas primitiver ist.

Locking mit fcntl:

int fd = open(path, O_RDWR);

struct flock lock;
memset(&lock, 0, sizeof(struct flock);
lock.l_type = F_WRLCK;
lock.l_whence = SEEK_SET;
lock.l_start = 0;
lock.l_len = 0;
fcntl(fd, F_GETLK, &lock);

Locking mit flock:

int fd = open(path, O_RDWR);

flock(fd, LOCK_EX);

Die Verlockung ist vielleicht groß, flock zu nutzen, wenn man nur schnell und einfach eine ganze Datei locken möchte. Ich würde aber empfehlen, immer fcntl zu nutzen, außer man möchte wirklich Locks mit mehreren Prozessen teilen.

Autor: Olaf | 0 Kommentare | Tags: unix, c

Linkdump

7. December 2017
Autor: Olaf | 0 Kommentare | Tags: links, unix, x11, history
Weiter