summaryrefslogtreecommitdiffstats
path: root/tde-i18n-sv/docs/tdebase/userguide/kde-as-root.docbook
blob: 030d9fdd2be9b1671849e6c02b99dffb0757505b (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
<sect1 id="root">

<sect1info>
<authorgroup>
<author
>&Francis.Giannaros; &Francis.Giannaros.mail; </author>
</authorgroup>
</sect1info>


<title
>Använda &kde; som systemadministratör</title>

<para
>Med &UNIX; operativsystem finns det ofta olika användare, som i sin tur kan ha olika rättigheter. Den konventionella metoden är att ha ett vanligt användarkonto, vars filer normalt är lagrade i <filename
>/home/användarnamn</filename
>, och dessutom ha ett konto kallat <systemitem class="username"
>root</systemitem
>. Kontot <systemitem class="username"
>root</systemitem
>, eller systemadministratören, har systemövergripande rättigheter, och kan ändra vilken fil som helst på systemet. </para>

<para
>Även om det betyder att det är enkelt att utföra administrativa uppgifter utan krångel, betyder det också att det inte finns några säkerhetsrestriktionerålagda det. Alltså kan ett litet typografiskt fel eller annat misstag leda till oåterkalleliga skador.</para>

<para
>Vissa av operativsystemen som kör &kde; levereras med grafisk inloggning aktiverad för <systemitem class="username"
>root</systemitem
>. Trots det, ska du aldrig logga in på &kde; som <systemitem class="username"
>root</systemitem
>, och du ska aldrig behöva göra det. Ditt system är mycket öppnare för attack, särskilt om du ansluter till Internet som <systemitem class="username"
>root</systemitem
>, och du ökar dramatisk risken att du skadar systemet.</para>

<para
>Vissa &Linux;-distributioner har försökt betona den här punkten så mycket att de har helt och hållet inaktiverat kontot <systemitem class="username"
>root</systemitem
>, och istället använder modellen med <command
>sudo</command
>. Trots det, är den grundläggande säkerhetsmodellen i <command
>sudo</command
> samma som <command
>su</command
>, och därför delar de väsentligen samma säkerhetsstyrkor och -svagheter.</para>

<para
>Om du någonsin skulle behöva köra ett program med rättigheter som systemadministratör, rekommenderas att du alltid använder &tdesu;. Skriv in <userinput
>tdesu <replaceable
>program</replaceable
></userinput
> från en terminal, eller genom att trycka på <keycombo action="simul"
>&Alt; <keycap
>F2</keycap
></keycombo
>, så körs programmet med lämpliga rättigheter som systemadministratör. </para>

<para
>Även om du har ställt in systemet att använda <command
>sudo</command
>, eller om du använder en distribution som använder <command
>sudo</command
>, som &kubuntu;, ska du ändå använda &tdesu;. Programmet ändras på lämpligt sätt av utvecklarna för att använda rätt inställningar. Du ska dock aldrig någonsin använda <command
>sudo <replaceable
>program</replaceable
></command
> för att köra ett program med rättigheter som <systemitem class="username"
>root</systemitem
>. Det kan bringa rättigheter för vissa av ett programs inställningsfiler i oordning. Att köra ett grafiskt program som <systemitem class="username"
>root</systemitem
> är i allmänhet inte en god idé, men att använda &tdesu; är alltid säkrast med det.</para>

<!-- Add links to "further reading" here -->
<itemizedlist>
<title
>Relaterad information</title>
<listitem
><para
><ulink url="help:tdesu"
>Handbok &tdesu;</ulink
></para>
</listitem>
</itemizedlist>


</sect1>

<!-- Keep this comment at the end of the file
Local variables:
mode: xml
sgml-omittag:nil
sgml-shorttag:nil
sgml-namecase-general:nil
sgml-general-insert-case:lower
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:0
sgml-indent-data:true
sgml-parent-document:("index.docbook" "book" "sect1")
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
-->