##  [Hvorfor ikke bare køre det hele som root?](/index.php/da/node/235) 

    *Indsendt af Lennart den ons, 3 jun 2026 - 19:31*  

  ![Hvorfor ikke bare køre det hele som root?](/sites/default/files/styles/wide/public/2026-06/composite_3.png.webp?itok=B9nBtP5A)

 

I de [to](https://docujai.com/da/node/233) [foregående](https://docujai.com/da/node/234) indlæg landede jeg på en konklusion: `enable-linger` var en lappeløsning, og den rigtige vej var at gøre min automatisering til ægte systemtjenester. I weekenden gjorde jeg det så.

Femten unit-filer flyttede fra brugerens systemd op på systemniveau. De gamle user-timere blev stoppet og slået fra, de nye blev lagt i `/etc/systemd/system/`, og bagefter kunne jeg endelig slå linger fra:

```
sudo loginctl disable-linger lk

```

Ingen tråd at holde i længere. Tjenesterne starter ved boot, rejser sig efter et nedbrud og er fuldstændig uafhængige af, om jeg er logget ind. Præcis som de skulle.

Men midt i det dukkede et godt spørgsmål op, som jeg tror mange stiller sig selv på det tidspunkt:

## "Hvorfor ikke bare køre det hele som root?"

Det er en rimelig tanke. Når man alligevel flytter tingene til systemniveau, er root da den enkleste model:

- Man slipper for `User=`, `Group=` og `HOME=` — kortere unit-filer.
- Ingen permission-problemer. Nogensinde.
- Simplere mental model: én bruger, der kan alt.

Og alligevel valgte jeg at lade hver tjeneste køre som min egen, almindelige bruger (`User=lk`) — ikke som root. Her er hvorfor, for det handler om mere end pænhed.

## 1. Filejerskab følger den, der skriver

Mine scripts skriver til `/home/lk/Data/...` og `/home/lk/logs/...`. Kører root dem, ender filerne med `root:root` som ejer. Næste gang jeg som almindelig bruger vil `tail`, `cat` eller redigere en logfil, får jeg permission-fejl. Eller værre: et andet script kan pludselig ikke læse den JSONL-fil, det er afhængigt af — og fejlen viser sig først langt senere, et helt andet sted.

## 2. Værktøjer er installeret pr. bruger

Min `PATH` peger på `/home/lk/.local/share/mise/shims/` — min egen installation af mit værktøj i mine versioner. Root har ikke nødvendigvis adgang til eller hensigt med at bruge den. Det kan fungere lige nu og så pludselig fejle efter en opdatering, fordi root kigger et andet sted hen.

## 3. Konfiguration bor i hjemmemappen

De fleste værktøjer læser deres config ud fra `$HOME` eller `$XDG_CONFIG_HOME` — typisk `~/.config/`. Mit AI-værktøj henter API-nøgler og modelvalg fra `~/.config/aichat/`. Kører tjenesten som root, leder den i `/root/.config/...`, som ikke findes. Så er nøglerne væk, og det rammer allerede ved første kørsel.

## 4. Eksplosionsradius, hvis et script har en fejl

Et script kan have en bug. En forkert variabel i et `rm`-kald, der rammer det forkerte sted. Kører det som min bruger, kan det i værste fald slette mine egne filer. Kører det som root, kan det røre `/etc/`, `/boot/` — hele systemet. Risikoen er realistisk lille. Men det er gratis at undgå.

## 5. Hemmeligheder følger brugeren

Lige nu er nogle credentials desværre hardkodet i scriptet. Den dag jeg flytter dem et ordentligt sted hen — `~/.netrc` eller en keyring — vil de ligge under min bruger, ikke under root. Tjenesten skal kunne finde dem dér, hvor de hører hjemme.

## Princippet bagved: kør med mindst mulig rettighed

Det her er ikke en finurlighed ved lige min opsætning. Det er et af de ældste og mest holdbare principper i drift: **giv en proces præcis de rettigheder, den har brug for — og ikke mere.**

Root er fristende, fordi det fjerner al modstand med det samme. Men den modstand var ofte information: en permission-fejl er systemet, der fortæller dig, at noget er ejet forkert, eller at en sti ikke passer. Kører alt som root, forsvinder den feedback — lige indtil dagen, hvor et uheld bliver dyrt i stedet for irriterende.

De fem ekstra linjer pr. tjeneste er billigere end at fejlsøge en root-konflikt om to måneder. Root er kun det klart rigtige valg, hvis tjenesten faktisk skal røre systemfiler, åbne en port under 1024 eller styre systemd selv. Det skal mine ikke. Så gør de ikke.

## Pointen, igen

Tre indlæg i streg er jeg endt samme sted: det vigtige spørgsmål er ikke "virker det?", men "hvem ejer det, og med hvilke rettigheder?". Linger handlede om at frigøre processen fra min login-session. Det her handler om ikke at give den mere magt, end den har brug for, bare fordi det er nemmere i dag.

For en virksomhed, der begynder at bygge automatisering, er det den slags valg, der ikke ses i en demo — men som afgør, om systemet er til at leve med om to år.