Komiskt falsklarm från Sophos

Sophos Antivirus misslyckades nyligen på ett ganska spektakulärt sätt:

On Wednesday, Sophos antivirus products did something very wrong: they started detecting false positives. The company has since fixed the issue, but only on Thursday did it become clear what the fiasco was all about: the Sophos software was detecting its own binaries as malware.

Programmet identifierade alltså en av sina egna komponenter som spyware, och tog bort den. Till råga på allt var det den del i programmet som genomför automatiska uppdateringar som "oskadliggjordes", så att de senare uppdateringar som rättade till felet inte kunde komma fram. Lätt lustigt är det.

Även om just det här fallet är litet ovanligt så är falsklarm inte ovanliga. På sätt och vis är de faktiskt önskvärda. Antivirusprogram fyller samma funktion som brandvarnare. De ska väsnas om det brinner, och det är bättre att det går tio falsklarm på varje verklig fara än att larmet har överseende med en eller annan eldsvåda mellan varven.

Sophos misslyckande var alltså egentligen inte att de råkade falsklarma, utan att de inte ordentligt testade uppdateringen som orsakade falsklarmet innan de skickade ut den.

Analogin håller faktiskt längre än så. När det brinner och larmet går så är det redan för sent och dags att släcka, sanera och göra något åt att brandsäkerheten är dålig. På samma sätt är det i princip redan för sent när ett antivirusprogram identifierar ett (verkligt) hot på datorn. Den skadliga koden har ju redan tagit sig in i maskinen. Då är det dags för en jobbig totalsanering och att sluta använda datorn på ett farligt sätt.

En bra början är att sluta använda Internet Explorer, om man nu fortfarande gör det. I samma veva bör man sluta med olika riskbeteenden på nätet, som att besöka och ladda ned från piratsajter, hålla på med porr eller googla på låttexter. (Det sista förvånade mig litet när jag hörde talas om det första gången.)

Det är även en bra idé att aldrig använda sig av öppna trådlösa nätverk – vare sig de är krypterade och kräver inloggning eller inte.

Roligt med mail, at och cron

I en kommande serie i åtminstone åtta delar har jag tänkt beskriva hur min eposthantering ser ut. Det dröjer dock litet. Visserligen vore det en lika hastig som smal sak att bara rapa upp programnamn och konfigurationsfiler, men det vore att ha för låga ambitioner. I stället siktar jag på något den fantastiske författaren Michael W. Lucas skrivit om:

One of the old cliches about writing is that you should “write what you know.” In tech writing this is not only wrong, but actively harmful. … Instead, I recommend writing about something you want to know about.

Det är därför det tar litet tid. Tomrummet som uppstår i väntan på de där inläggen går dock att fylla med små finurligheter som inte egentligen uppfyller några sådana krav. Här kommer ett par av det slaget.

Om du har sendmail eller motsvarande i ordning på din maskin så kan du skicka epost med programmet mail.

Till exempel så här:

$ mail jesper
Subject: Lokalpost
Any fool can paint a picture, but it takes a wise person to be able to
sell it.
EOT

EOT var resultatet av att jag tryckte ^D (vilket betyder CTRL-D). Det här mejlet levereras omedelbart till den lokala användaren jesper, vilket ju är jag själv. Det går förstås även att skicka till en riktig epostadress:

$ mail jesper@example.org
Subject: Globalpost
Pig, n.:
        An animal (Porcus omnivorous) closely allied to the human race
        by the splendor and vivacity of its appetite, which, however, is
        inferior in scope, for it balks at pig.
                -- Ambrose Bierce, "The Devil's Dictionary"
EOT

Men med min konfiguration levereras aldrig det senare mejlet!

En del av förklaringen till detta är att sendmail på min maskin använder en "SMART_HOST", alltså en extern STMP-server som relay, och den servern accepterar inte de här epost-meddelandenas avsändaradress.

Om inget annat anges, så får epost skickade med mail nämligen avsändaren användare@maskin, till exempel "jesper@kaja.mydomain", och relay-servern förkastar mejl från sådana ogiltiga avsändare.

Detta är dock lätt att lösa. Om man matar mail med flaggor efter mottagaradressen, så skickas de vidare till sendmail i stället för att tolkas av mail. För att skicka ett mejl till jesper@example.org med en bestämd avsändaradress gör jag alltså så här:

$ mail jesper@example.org -f fortune@example.org
Subject: Fortune
Top scientists agree that with the present rate of consumption, the
earth's supply of gravity will be exhausted before the 24th century.
As man struggles to discover cheaper alternatives, we need your help.
Please...

                        CONSERVE GRAVITY

Follow these simple suggestions:

(1)  Walk with a light step.  Carry helium balloons if possible.
(2)  Use tape, magnets, or glue instead of paperweights.
(3)  Give up skiing and skydiving for more horizontal sports like
     curling.
(4)  Avoid showers ... take baths instead.
(5)  Don't hang all your clothes in the closet ... Keep them in one big
     pile.
(6)  Stop flipping pancakes
EOT

Förutsatt att avsändaradressen fortune@example.org är giltig kommer det här mejlet levereras.

Och nu börjar det roliga, eller rättare: Nu gör vi oss av med det tråkiga.

Först och främst är jag trött på att varje gång jag vill skicka mejl som de här behöva köra fortune, kopiera och till sist klistra in det i mina mejl. Samma resultat går ju att uppnå på det här viset:

$ fortune -a | mail -s "Kakan säger" jesper@example.org -f fortune@example.org

Observera hur flaggan -s, som bestämmer Subject, ligger före mottagaradressen och därmed tolkas av mail i stället för att skickas vidare till sendmail.

Nästa grej jag är trött på är att skicka de här mejlen manuellt, för att sedan få dem levererade några sekunder senare. Därför skickar jag dem i stället med hjälp av programmet at, vars poäng helt enkelt är att köra ett eller flera kommandon vid en annan tidpunkt än omedelbart:

$ at 07:45
fortune -a | mail -s "Kakan säger" jesper@example.org -f fortune@example.org
^D

Med detta schemaläggs skickandet till klockan kvart i åtta på morgonen, nästa gång hon är så mycket. at förstår även mer avancerade tidsangivelser, exempelvis teatime september 7 som inträffar kl. 16.00 nästkommande 7/9. (Ett tråkigare sätt att uttrycka samma tidpunkt är annars 201209071600).

Men så här roligt vill jag inte bara ha någon gång ibland och på eget initiativ, utan varje dag. Att mejla en fortune till sig själv passar mycket bättre i cron, som finns till för att köra kommandon vid upprepade tillfällen.

Det finns massor av sätt att konfigurera körningar i cron, som något visst datum varje månad, en viss minut varannan timme, varje söndag och så vidare. Jag är dock bara intresserad av klockslaget kvart i åtta varje morgon. För att fixa detta gör jag crontab -e och pular in den här raden:

Att 45 är en minut och 7 en timme är lätt att inse. De tre asteriskerna i sin tur, står i tur och ordning för datum, månad och veckodag.

Det går även att mata in kommaterade listor eller spännvidder. Här är en variant som skickar det där mejlet varje vardagsmorgon klockan kvart i åtta, förutom i juli:

Visserligen är det svårt att tänka sig något roligare innehåll för automatiska mejl än fortune, men det är nog bäst om jag täcker något praktiskt användningsområde också.

urlwatch.sh

För det här avsnittet var jag först inne på att jag skulle reproducera Richard Stallmans oerhört praktiska webbläsare, men kom som tur var på bättre tankar.

Det blir dock något liknande, nämligen en webbövervakningstjänst. För att åstadkomma denna tar jag hjälp av ett gammalt skript som nyligen fick sig en omgång och kom online: urlwatch.sh.

Med en default-konfiguration läser urlwatch.sh in ett godtyckligt antal whitespace-separerade url:er ur filen ~/.urlwatch/urls, drar ned dem med curl, tolkar om dem till plaintext med lynx och sparar resultatet i en cache. Andra gången skriptet körs hämtar det samma sidor igen, skriver ut en diff mellan den föregående och nuvarande versionen av sidorna och uppdaterar sedan cache-kopian.

Det här skriptet vill jag köra från cron ett par gånger om dagen, bland annat för att få en ping via epost när SVT Play slänger upp nya program på vissa adresser, exempelvis http://www.svtplay.se/agenda. De övergav ju RSS när de bytte till ny sajt i somras.

För att åstadkomma detta installerar jag först skriptet:

$ curl -o bin/urlwatch.sh \
https://raw.github.com/simio/scripts/4f1d265852529fab701f1ce817a15611839047a8/urlwatch.sh
$ mkdir ~/.urlwatch
$ echo "http://www.svtplay.se/agenda" > ~/.urlwatch/urls

(Byt hashen i adressen till master för att hämta den senaste versionen.)

Sedan lägger jag till det i min crontab (med crontab -e, igen):

Observera att det där inte ska vara flera rader, utan bara en. När den här crontabben är sparad kommer skriptet köras klockan 06.00, 12.00 och 18.00 varje dag, och utmatningen mejlas till jesper@example.org vare sig den är tom eller inte.

Flaggan -f till urlwatch.sh gör att skriptet rapporterar diffar i ett format som passar bättre i mejl.

Mejlprogram som försöker vara listiga kan förresten sabba det här genom att sortera bort epost med samma avsändare som mottagare. GMail är en sådan skurk. Du behöver i så fall ange en annan avsändaradress.

Det är dock inte som ovan jag egentligen använder skriptet i min crontab. Eftersom jag använder min lokala mailspool ser jag för det första till att rapporterna aldrig lämnar datorn, genom att skicka dem till mitt användarnamn i stället för min epostadress.

Sedan vill jag inte heller ha rapporter när ingenting hänt, vilket blir resultatet om man använder skriptet som ovan. I stället låter jag skriptet själv sköta mejlandet. Som en bonus blir allting därmed mycket mindre komplicerat i crontabben.:

Timangivelsen */2 betyder varannan timme.

Flaggan -m säger åt urlwatch.sh att skicka rapporten som epost i stället. Mottagare kan bestämmas med flaggan -r, men eftersom defaultvärdet är den användare som kör skriptet behöver jag inte använda den.

Default-värdet för avsändaradress är daemon@localhost, men vill du ändra det så ska du lägga till den här raden i filen ~/.urlwatch/config:

Nu är det slut på det roliga.

Allting är vitt vitt vitt

I går tröttnade jag till slut på mitt gamla tema Kebnekaise (tänkt för att ersätta K2) och bytte till något bredare… och vitare. Förhoppningsvis blir ingen ledsen. (Men du milde vicke vitt!)

xsudo.sh – en skriptad X11-wrapper för sudo

För att fira slutet av min exil i Windows skriver jag en följetong om de olika program, inställningar och knep som gör mitt sätt att använda OpenBSD… ja, värt att fira.

Gårdagens inlägg handlade om att byta plats på Escape och Caps lock, och var en uppfräschning av ett tidigare inlägg. I dag är det dags för en uppdatering av ett annat gammalt inlägg, som beskriver hur man kan köra X11-program som andra användare eller root.

Själv använder jag den här metoden för att köra webbläsare som användaren _web med hemkatalogen /home/_web. Därigenom saknar webbläsaren skrivrättigheter under min hemkatalog, och kan inte sabba något.

Eftersom jag dessutom kör med umask 077 i min .profile och med jämna mellanrum gör chmod -R og-rwx på min hemkatalog, kan webbläsarna inte heller läsa mina filer. Den enda nackdelen med det upplägget är inte så blodig: När jag vill ladda upp eller ned något genom webbläsaren måste jag låta filerna ifråga passera /tmp (som för övrigt töms automatiskt av OpenBSD vid uppstart, och dessutom är mountad async på min maskin).

Det här upplägget borde fungera i de allra flesta X11-varianter, exempelvis X.org.

sudo och $SUDO_ASKPASS

Du känner kanske till gksudo och kdesudo, två grafiska sudo-prompter för GNOME respektive KDE? De är smidiga när man vill köra ett X11-program som någon annan användare eller root, men inte vill ta en omväg över xterm.

Men de är utom räckhåll här, eftersom jag inte vill ha vare sig KDE eller GNOME. Som tur är behövs de inte heller, för samma funktionalitet uppstår i det närmaste av sig självt, om man bara har OpenSSH installerat. Det följande är klippt ur sudo (8):

-A    Normally, if sudo requires a password, it will read it from
      the user's terminal.  If the -A (askpass) option is
      specified, a (possibly graphical) helper program is executed
      to read the user's password and output the password to the
      standard output.  If the SUDO_ASKPASS environment variable is
      set, it specifies the path to the helper program.  Otherwise,
      the value specified by the askpass option in sudoers(5) is
      used.  If no askpass program is available, sudo will exit
      with an error.

Vi behöver med andra ord något enkelt program som visar ett fönster, läser in ett lösenord och sedan trycker ut det på standard output. Programmet heter ssh-askpass. Manualsidan ssh-askpass (1) menar att det inte ska köras direkt, men det struntar jag i.

Följande skript skulle alltså kunna fungera:

Men ska det verkligen vara så lätt? Vi provar att köra xcalc som användaren _web:

$ sh bin/xsudo.sh -Hu _web xcalc
No protocol specified
Error: Can't open display: :0

Visst ja – användaren _web har ju ingen åtkomst till min X11-server. Det är nu allt blir krångligt.

Display-åtkomst i X11

Säkerhet och X11 går inte direkt hand i hand, och de säkerhetsmekanismer som faktiskt finns är svåranvända påbyggnader som alltjämt riskerar att rasa samman. När en X11-session startas på din maskin, så är det i själva verket två program som drar i gång. Först en X11-server, och sedan en X11-klient. Medan servern kör alla program är det klienten som direkt kommunicerar med dig via tangentbord, mus och skärm.

En fördel med den modellen är att klient och server inte alls behöver vara på samma maskin. I vanliga fall, t.ex. på hemdatorer, ansluter klienten till servern via loopback-gränssnittet, alltså till adressen localhost eller 127.0.0.1.

Det som i själva verket händer när xcalc försöker komma åt X11 i vårt xsudo-skript ovan, är att servern nekar användaren _web att ansluta. Tre lösningar på det problemet är vanligt förekommande.

  1. xhost kan användas för att ge full åtkomst till din X11-display åt en viss användare på samma maskin. (Programmet kan även ge full åtkomst till alla användare på valfri IP-adress, men det är en dålig idé.)
  2. xauth kan användas för att ge full eller begränsad åtkomst till din X11-display åt en användare eller ett program, vare sig de finns på samma maskin eller någon annan.
  3. ssh kan alternativt köras med X11 forwarding, och ger då begränsad åtkomst till din X11-display.

Vill vi använda begränsad eller full åtkomst? Det beror på. Begränsad åtkomst innebär att bland annat accelererad grafik och direkt åtkomst till X input devices inte fungerar. Grafiskt intensiva program, som exempelvis webbläsare faktiskt är, går därför långsammare med begränsad åtkomst. En annan nackdel är att AltGr kan sluta fungera.

När det är möjligt bör man ändå använda begränsad åtkomst. Det är ganska lätt att visa varför. Om du själv vill prova det följande ska du se till att ha xinput på din maskin.

kaja$ xhost +si:localuser:_web # Släpp in lokal användare '_web' i X11
localuser:_web being added to access control list
kaja$ xinput list # Lista alla input devices
+ Virtual core pointer                  id=2    [master pointer  (3)]
|   + Virtual core XTEST pointer        id=4    [slave  pointer  (2)]
|   + /dev/wsmouse0                     id=7    [slave  pointer  (2)]
|   + /dev/wsmouse                      id=8    [slave  pointer  (2)]
+ Virtual core keyboard                 id=3    [master keyboard (2)]
    + Virtual core XTEST keyboard       id=5    [slave  keyboard (3)]
    + /dev/wskbd                        id=6    [slave  keyboard (3)]
kaja$ sudo -u _web xinput test 6 # Dumpa händelser på device 6
key release 36
key press   33
key release 33
key press   38
key release 38
key press   39
key release 39
key press   39
key release 39
key press   25
key press   32
key release 25
key release 32
key press   27
key release 27
key press   40
key release 40

Vad var det egentligen som hände? Med xinput list listade jag alla aktiva X input devices, och kom fram till att tangentbordet var device nummer 6. Sedan körde jag xinput test 6 som användaren _web, och skrev därefter "password" i ett annat fönster, som jag körde i egenskap av mig själv. Trots att jag skrev i ett fönster som tillhörde användaren jesper, och till råga på allt i ett lösenordsfält, så kunde användaren _web se exakt vilka tangenter jag tryckte ned (och släppte upp, för den delen).

Med andra ord kan vilket program som helst, oavsett vilken användare som kör det, avläsa alla nedslag på tangentbordet, oavsett vilket program som "egentligen" tar emot dem, så länge det har full åtkomst till X11-displayen.

Exceptionellt illa. Så pass illa att om du bara lyckas peta in ett xhost localhost på någon dator du har åtkomst till via ssh, så är det följande en fungerande keylogger:

kaja$ ssh struts xinput test 6

…förutsatt att tangentbordet är device 6 på maskinen struts, då. Detta är förklaringen till varför xhost-autentisering mot någon annan dator än localhost är så dåligt. Med en sådan regel på plats behöver man inte ens ha tillgång till maskinen via exempelvis ssh, utan kan köra sin keylogger direkt mot maskinens IP-adress.

Lätt skrämmande. Med begränsad åtkomst kan vi däremot inte göra några sådana hyss. I exemplet nedan ansluter jag till min egen maskin (som heter kaja) via ssh för att få en session utan full åtkomst.

kaja$ ssh -o ForwardX11=yes localhost
kaja$ xinput list
X Input extension not available.
kaja$ xinput test 6
X Input extension not available.

Mycket bättre, men som sagt också fritt från både grafisk acceleration och AltGr.

Vilken typ av autentisering ska vi då välja?

Alternativ 3, alltså X11 över ssh, är inte intressant för oss, eftersom samma resultat kan uppnås utan att belasta processorn med en krypterad anslutning till localhost.

Alternativ 1, alltså att köra xhost för en lokal användare, är visserligen användbart när vi behöver full åtkomst, men klarar inte att ge begränsad åtkomst. Vi vill kunna välja.

Kvar blir alltså alternativ 2, att använda xauth, som givetvis är krångligast.

xsudo.sh – en skriptad X11-wrapper för sudo

Efter en blick (eller tjugotre) i xauth (1) verkar följande ordning gångbar:

  1. Skapa en tom, privat och tillfällig fil i /tmp.
  2. Be X11-servern om en MIT-cookie (som är trusted eller untrusted beroende på om vi vill ha full eller begränsad åtkomst) och placera denna i den tillfälliga filen.
  3. För över ägandet av den tillfälliga filen till användaren vi vill bli.
  4. Kör sudo för användaren vi vill bli, med XAUTHORITY satt till vår temporära fil och DISPLAY till den X11-display som kakan vi skapat gäller för.
  5. Ta bort den tillfälliga filen när sudo (och det program som sudo startat) avslutats.

Bäst att ge ett praktiskt exempel. Nedan körs xcalc som _web med begränsad åtkomst.

$ umask 077                                 # Bli privat
$ mktemp                                    # Skaffa en tempfil
/tmp/tmp.OVZCpcwL4A
$ xauth -f /tmp/tmp.OVZCpcwL4A generate \   # Skapa cookie i filen...
    $DISPLAY \                              # ...för DISPLAY
    . \                                     # ...av MIT-COOKIE-typ
    untrusted                               # ...med begränsad åtkomst
$ sudo chown _web._web /tmp/tmp.OVZCpcwL4A  # Ge ägande till _web
$ sudo -AHu _web \                          # Bli _web...
    env DISPLAY=$DISPLAY \                  # ...med rätt X11-display
    env XAUTHORITY=/tmp/tmp.OVZCpcwL4A \    # ...och rätt MIT cookie
    xcalc                                   # ...och kör xcalc
$ rm -f /tmp/tmp.OVZCpcwL4A                 # Ta bort tempfilen

Och för att hoppa över ett närmast oändligt antal steg: Så här ser ett skript som automatiserar processen ut:

(Givetvis kan du även läsa den senaste versionen av skriptet.)

Hur använder man då skriptet? Vi kan ju börja med att testa det:

kaja$ sh /usr/opt/bin/xsudo.sh whoami  
root
kaja$ sh /usr/opt/bin/xsudo.sh -u _web whoami
_web
kaja$ sh /usr/opt/bin/xsudo.sh -tu _web xinput list
+ Virtual core pointer                  id=2    [master pointer  (3)]
|   + Virtual core XTEST pointer        id=4    [slave  pointer  (2)]
|   + /dev/wsmouse0                     id=7    [slave  pointer  (2)]
|   + /dev/wsmouse                      id=8    [slave  pointer  (2)]
+ Virtual core keyboard                 id=3    [master keyboard (2)]
    + Virtual core XTEST keyboard       id=5    [slave  keyboard (3)]
    + /dev/wskbd                        id=6    [slave  keyboard (3)]
kaja$ sh /usr/opt/bin/xsudo.sh xinput list        
X Input extension not available.

Lägg märke till hur flaggan -t ger sådan där otäck åtkomst till tangentbordet.

Lägg även märke till att jag lagt skriptet i /usr/opt/bin/ i stället för under min hemkatalog; skript som kör sudo ska ägas av root och vara oskrivbara för andra användare.

För att starta Chromium med xsudo.sh har jag kopplat ett menyalternativ i fönsterhanteraren till följande formel:

/bin/sh /usr/opt/bin/xsudo.sh -tu _web /usr/local/bin/chrome

Trots X11:s skrämmande brist på isolering mellan program kör jag alltså webbläsaren med full åtkomst, dels för att det går långsamt utan acceleration och dels för att det är tråkigt att behöva kopiera in tecken som @ och $ från något annat fönster – AltGr fungerar ju som sagt inte med begränsad åtkomst. Det får räcka med att webbläsaren inte kommer åt filerna under min hemkatalog.

Pidgin klarar sig däremot utan sådana finesser:

/bin/sh /usr/opt/bin/xsudo.sh -u _web /usr/local/bin/pidgin

Och tar man även bort "-u _web" ur ovanstående så körs pidgin förstås som root.

Om du nu vill börja köra något program som en annan användare, så vill du antagligen även flytta över programmets dotfiles till den andra användarens hemkatalog, innan du drar i gång programmet.

För Chromium och användaren _web ser processen ut så här:

kaja$ umask 077
kaja$ sudo -u _web mkdir -p ~_web/.config
kaja$ sudo cp -r ~/.config/chromium ~_web/.config/
kaja$ sudo chown -R _web._web ~_web/.config/chromium

Det var det hela. Skriptet kommer bo och uppdateras på diskussionsforumet.

Byta plats på Escape och Caps Lock

cPS LOCK ÄR EN FÖRBnnat störig tangent innan man lär sig låta bli den. Lyckligtvis går den att flytta på, utan att man för den sakens skull ska behöva pilla med själva tangentbordet.

Ett sätt att göra detta i X11 beskrev jag för ett drygt år sedan. Metoden fungerar dock inte längre, åtminstone inte i OpenBSD 5.2-current, så här kommer en uppdatering.

Utanför X11

All sin tid vid tangentbordet spenderar man ju inte i X11. I OpenBSD är det wscons (4) som mappar tangenter för konsolen, och därför är det wsconsctl.conf (5) som ska redigeras.

De här två raderna bakar kakan:

keyboard.map+="keycode 1 = Caps_Lock"
keyboard.map+="keycode 58 = Escape"

När det receptet är på plats i /etc/wsconsctl.conf växlas tangenterna från och med nästa uppstart. Kan du inte hålla dig till dess så ska du omedelbart mata wsconsctl (8) med samma rader:

$ wsconsctl keyboard.map+="keycode 1 = Caps_Lock"
$ wsconsctl keyboard.map+="keycode 58 = Escape"

Vill du göra samma sak i Linux, då får du vända dig till en sökmotor, till något lämpligt forum eller RTFM (om det finns någon). Gissningsvis körs tangentbordsmappningen någonstans i uppstartsprocessen, t.ex. /etc/init.d eller motsvarande, så din upptäcktsresa kan börja där.

Inuti X11

Ovanstående är dock till föga glädje när X11 väl startar. X11 mappar nämligen om tangentbordet vid uppstart. Till råga på allt känner OpenBSD:s X11 inte längre igen tangentbordet som ett svenskt sådant om ovanstående inställningar är gjorda, vilket innebär att man påtvingas ett engelskt tangentbord. (Egentligen är det wscons som rapporterar mappningen som "user" i stället för "sv" så snart den förändras.)

Ett steg framåt men två tillbaka.

Nå, vi ordnar först så att det svenska tangetbordet kommer tillbaka, genom att placera följande rad i ~/.xinitrc, förslagsvis mycket tidigt, men inte först, i filen:

/usr/X11R6/bin/setxkbmap se

Kör även kommandot i ett terminalfönster för att slippa starta om X11.

Nu har vi vårt svenska tangentbord tillbaka, men förtretligt nog sitter Escape och Caps lock precis där de brukar igen – X11 gör ju som sagt sin egen tangentbordsmappning. För att lägga oss i denna använder vi xmodmap (1).

Processen är enkel:

$ xmodmap -e 'clear Lock'
$ xmodmap -e 'keysym Escape = Caps_Lock'
$ xmodmap -e 'keycode 0x42 = Escape'

Nu vill man förstås inte gärna göra det där varje gång man startat X11, så vi permanentar inställningarna genom att lägga dem i filen ~/.Xmodmap, som vi sedan kör från ~/.xinitrc.

Eventuellt har du redan någon slags anordning i din ~/.xinitrc som använder .Xmodmap, .xmodmap eller i värsta fall någon helt annan fil. Kolla först detta, och utgå sedan från vad du redan har, om du har något.

Filen ~/.Xmodmap (eller motsvarande) ska innehålla följande:

I ~/.xinitrc ser det i stället ut så här:

Tänk på att tjo-pangen (dvs "#!/bin/sh") ska vara först i filen. Sedan har man förstås mycket mer i en vettig ~/.xinitrc, men om det ska jag skriva först i ett senare inlägg.

Om du inte hade någon ~/.xinitrc är det lämpligt att du skaffar en innan du ändrar i den. Det kan du göra genom att kopiera /etc/X11/xinit/xinitrc eller motsvarande till ~/.xinitrc.

Det var det hela. Nu har du Escape i samma kvarter som vänster lillfinger, och behöver knappt lyfta det för att stänga dialogrutor, avbryta sidladdningar eller använda en vettig texteditor. Gött!

(För säkerhets skull upprepar jag även tipset från mitt tidigare inlägg: I Windows kan man göra samma tangentbyte med SharpKeys.)