Det här avsnittet är i huvudsak ämnat för systemadministratörer (root), de med höga säkerhetskrav eller helt enkelt tekniskt intresserade. Det är inte nödvändigt att läsa det här om du bara använder &Linux; hemma själv, även om du i alla fall kan lära dig ett och annat. En systemadministratör kan vilja begränsa tillgången med avseende på vem som får använda &kppp;. Det finns två sätt att åstadkomma detta. Skapa en ny grupp (du skulle kunna vilja döpa den till dialout eller något liknande), och lägg till alla användare som ska få lov att använda &kppp; i den här gruppen. Skriv sedan på kommandoraden: # chown root.dialout /opt/kde/bin/kppp # chmod 4750 /opt/kde/bin/kppp Det här förutsätter att &kde; installerades i /opt/kde/ och att den nya gruppen heter dialout. Innan det gör någonting, kontrollerar &kppp; om det finns en fil som heter /etc/kppp.allow. Om den här filen finns, tillåts bara användare som namnges i den här filen att ringa upp. Den här filen måste vara läsbar av alla (men förstås INTE skrivbar). Bara inloggningsnamn känns igen, så du kan inte använda en UID i den här filen. Här är ett kort exempel: # /etc/kppp.allow # kommentarrader som den här ignoreras # precis som tomma rader hans karl lena I det ovanstående exemplet, tillåts bara användarna hans, karl och lena att ringa upp, liksom alla användare med UID 0 (så du behöver inte explicit ange root i filen). Det är mer eller mindre omöjligt att skriva ett uppringningsprogram som både är säkert och lätt att använda för ovana användare utan att sätta SUID-biten. &kppp; hanterar säkerhetsproblemen med följande strategi. Omedelbart efter att programmet har startat, så skapar &kppp; en ny process (fork). Huvudprocessen, som hanterar hela det grafiska gränssnittet med användarpåverkan, släpper SUID-tillståndet efter den nya processen skapats, och kör med normala användarrättigheter. Den nya processen behåller sina rättigheter, och ansvarar för alla åtgärder som behöver rättigheter som root. För att hålla den här delen säker, så används inga anrop till &kde;- eller &Qt;-biblioteken, utan bara enkla biblioteksanrop. Källkoden för den här processen är kort (omkring 500 rader) och väldokumenterad, så det är lätt att kontrollera den för att hitta säkerhetsluckor. Huvudprocessen och den nya processen kommunicerar med vanliga &UNIX; IPC. Särskilt tack till Harri Porten för att ha skrivit den här utmärkta koden. Det ansågs omöjligt, men han lyckades inom en vecka.