[gelöst] Updates richtig machen

[willy4711]

Ich würde einfach die fürs updaten relevanten Befehle in ein Bashscript schreiben und die Policy auf dieses Script anwenden. Dann wäre das schlimmste, wofür diese Policy genutzt werden kann, ein Update des Systems durchzuführen. Der Missbrauch für andere Funktionen wäre damit jedenfalls wirksam unterbunden.

Da geht auch einfacher, indem man die Policy nach Geschmack so umschreibt:

Code: Alles auswählen

<defaults>
        <allow_any>auth_admin</allow_any>
        <allow_inactive>auth_admin</allow_inactive>
        <allow_active>auth_admin_keep</allow_active>
    </defaults>

oder

Code: Alles auswählen

<defaults>
        <allow_any>auth_admin</allow_any>
        <allow_inactive>auth_admin</allow_inactive>
        <allow_active>auth_admin</allow_active>
    </defaults>

Ach ja, mein Update-Skript hat natürlich 555 ganz so leichtfertig bin ich nun doch nicht

Code: Alles auswählen

~$ ls -al /usr/local/bin/update
-r-xr-xr-x 1 root root 136 Aug 14 16:45 /usr/local/bin/update

alles wirklich klinisch rein, so wie es sein soll. Ist doch so, oder?

Ist natürlich nicht so. Ich halte auch nichts von der "reinen Lehre", solange ich die Programme, die ich zusätzlich nutze
halbwegs überblicke, kontrollieren kann, was sie wohin in das System kritzeln. Das steht ja in der Regel in den deb- Paketen,
die man sich mal vorher ansehen kann.
Bei z.B Virtualbox fühle ich mich sicherer als z.B. bei qemu /kvm.
Man muss bloß mal bei Cert danach suchen. --> Also vertraue ich diesem Repo mindestens so, wie einem Debian - Paket.
JRiver vertraue ich seit fast 20 Jahren, und das wird auch so bleiben, weil es keine Alternative gibt.
deb.multimedia halte ich für genauso vertrauenswürdig wie ein Debian Repo
Und Enpass ist als PW-Manager halt universell einsetzbar auf allen Browsern

Aber darüber will ich gar nicht diskutieren, wollte es nur gesagt haben.

[TomL]

Da geht auch einfacher, indem man die Policy nach Geschmack so umschreibt:

Code: Alles auswählen

<defaults>
        <allow_any>auth_admin</allow_any>
        <allow_inactive>auth_admin</allow_inactive>
        <allow_active>auth_admin_keep</allow_active>
    </defaults>

oder

Code: Alles auswählen

<defaults>
        <allow_any>auth_admin</allow_any>
        <allow_inactive>auth_admin</allow_inactive>
        <allow_active>auth_admin</allow_active>
    </defaults>

Na ja, die Änderung schließt zwar die Lücke, aber einen echten Sinn kann ich nicht darin erkennen. Dann kann ich doch mit gleichem Aufwand auch "su -" verwenden und starte dann mein Script. Das nervige (und bei mir echte Problem) ist bei mir ein root-Password mit hohem Vertipper-Potential für hektische Finger. *fg* Also ich wollte für so einen banalen regelmäßigen Kram nicht jedesmal mein Pwd eintippen müssen. Bei mir gibts deshalb die Policy auf das Script.... und zwar mit 'yes'. Das wird einfach mit "pkexec autoupdate" gestartet.

[debianuser4782]

Nach dem Lesen einiger Beiträge in diesem Thread stellen sich mir nun folgende Fragen:
Besteht ein Risiko, wenn ich mich zu Hause auf der Console (tty) oder im Terminal als root einlogge und dann aus Bequemlichkeitsgründen bis zum Ende der Sitzung eingeloggt bleibe? Bei mir laufen iftop und journalctl -f als root während der ganzen Sitzung. Dies müsste doch eigentlich ein größeres "Risiko" darstellen als ein solch "offenes Terminal".
Und was ist eine root-shell? Sind damit bereits die Console oder das Terminal gemeint?
Diese Fragen stelle ich mir schon länger.

Tip: Wer nicht immer sein user- oder root-Passwort eintippen möchte und wer lange und komplexe Passwörter setzt, kann einen Yubi- oder Onlykey verwenden. Diese werden vom System als schlichte Tastaturen behandelt (dh ua die Zwischenablage bekommt nichts zu Gesicht). Risiken: das versehentliche Auslösen von Passwortausgaben im falschen Fenster und das Konfigurieren solcher Token auf einem Computer mit Verbindung zum Internet.

[TomL]

Nach dem Lesen einiger Beiträge in diesem Thread stellen sich mir nun folgende Fragen:
Besteht ein Risiko, wenn ich mich zu Hause auf der Console (tty) oder im Terminal als root einlogge und dann aus Bequemlichkeitsgründen bis zum Ende der Sitzung eingeloggt bleibe? Bei mir laufen iftop und journalctl -f als root während der ganzen Sitzung.

Ich sehe das nicht als Risiko. Es sind halt Prozesse, die mit root-Rechten laufen, fertig. Wobei das für das Journal eigentlich gar nicht notwendig ist. Wenn Du Dich in die Journal-Gruppe einträgst, solltest Du das auch als nicht-root lesen dürfen. Für iftop würde ich eine Policy erstellen, die Dir erlaubt, das Programm direkt mit 'pkexec iftop' als root zu starten. Solange dir keiner ein anderes iftop unterjubelt, kann man dabei vermutlich sogar das Password deaktivieren. Ich hätte da jetzt keine Bauchschmerzen.

Dies müsste doch eigentlich ein größeres "Risiko" darstellen als ein solch "offenes Terminal".

Nö, warum?

Und was ist eine root-shell? Sind damit bereits die Console oder das Terminal gemeint?

Eine root-Shell ist -so interpretiere ich das- eine Console (oder Terminal) in der root bereits angemeldet ist. Ist es ein vom User gestartetes Terminal, sehe ich das als normale unprivilegierte User-Shell, nach erfolgreichen su - wirds dann zur root-shell.

Tip: Wer nicht immer sein user- oder root-Passwort eintippen möchte

...erstellt sich eine Policiy.... sofern der Prozess eine isolierte Aufgabe hat und nicht dazu verwendet werden kann, das System oder die vorhandenen Rechteeinstellungen zu verändern. Einen Hardware-Key nehme ich beim Entschlüsseln meiner Reise-Laptop-Daten-Partition. Sicher, ich bin natürlich sehr vorsichtig, aber ich versuche auch nicht Paranoid zu sein. Und manchmal sind die Freiheiten, die ich mir selber gönne, nicht die gleichen, zu denen ich hier öffentlich rate *fg* Aber ich glaube, ich kann die Risiken meiner Freiheiten heute recht gut einschätzen.

[willy4711]

Nur noch mal zu dem Ablauf bei mir:
Der package-update-indicator zeigt mir durch eine Notifikation an, ob und wie viel Updates vorhanden sind oder nicht.
Gleichzeitig ändert er das Icon im Tray.
Dann kann ich entweder sofort oder wann es mir gefällt mit einem Klick auf das Icon das Update starten.
Von dort wird auch das schreibgeschützte Skript (555) aufgerufen.
Offene Root-Terminals gibt es nur während der direkten Ausführung des Befehls.Ist der Befehl ausgeführt,
schießt das Terminal sofort und automatisch.

[rockyracoon]

Als fleißiger, braver und lernbereiter meist nur Mitleser, habe ich genau die Manpage zur Root-Anmeldung gelesen.
Daraus geht imho hervor, dass man, will man ganz korrekt und fehlerfrei vorgehen, nicht nur "su -" statt lediglich "su" eingeben sollte, sondern sogar "su --login":

...
Aus Es wird empfohlen, stets die Option --login (statt deren
Kurzform -) zu verwenden, um durch Mischen der Umgebungen verursachte
Nebenwirkungen zu vermeiden.
...

Zitat aus der Manpage "SU(1) Dienstprogramme für Benutzer"

Bezüglich des Thread-Titels "Updates richtig machen" wäre die präziseste Antwort imho dann wohl:
Terminal öffnen > su –-login > Root-Passwort > apt update && apt full-upgrade && apt autoremove && apt autoclean

[willy4711]

Ich hatte mal was dazu geschrieben:
viewtopic.php?f=27&t=177709&p=1240934&h ... n#p1240934

su -
oder
su -l
oder
su --login
statt. Alle 3 Kommandos sind identisch

Kannst dir aber noch einen weiteren Knoten in deinen Beine machen, und es "ganz korrekt" schreiben:

Code: Alles auswählen

su --login root

Oder jeden anderen bei dir vorhandenen User
z.B.

Code: Alles auswählen

willy@debian:~$ su --login egon
Passwort: 
egon@debian:~$ 

Edit

Kannst auch mal die ArchWiki zu Rate ziehen: https://wiki.archlinux.org/index.php/Su
und dir in deiner ~/.bashrc einen alias genehmigen
Aber hinterher die bashrc bittschön mit dem Attribut "i" versehen, damit sie keiner ändern kann

Aber letztendlich sieht man doch am Prompt, in welcher Umgebung man sich bewegt.
Dachte ich bisher jedenfalls.

[TomL]

Dann kann ich entweder sofort oder wann es mir gefällt mit einem Klick auf das Icon das Update starten.
Von dort wird auch das schreibgeschützte Skript (555) aufgerufen.
Offene Root-Terminals gibt es nur während der direkten Ausführung des Befehls.Ist der Befehl ausgeführt,
schießt das Terminal sofort und automatisch.

Willy, Du hast es offensichtlich immer noch nicht verstanden. Vor dem Hintergrund Deiner Policy ist es

• völlig bedeutungslos, ob die Script-Attribute 555 sind, weil jeder unprivilegierte User jederzeit andere Attribute setzen kann, um dann die Datei beliebig zu ändern - ganz wie er mag, ohne Password-Abfrage, weil Du das erlaubt hast.
• völlig bedeutungslos, ob es ein offenes oder geschlossen root-Terminal ist, weil sich jeder unprivilegierter User jederzeit ein eigenes root-terminal öffnen kann - ganz wie er mag, ohne Password-Abfrage, weil Du das erlaubt hast.
• völlig bedeutungslos, ob das root-terminal nur während des script-laufes offen ist, weil jeder unprivilegierter User sich gleichzeitig oder auch zu jeder anderen Zeit ein, zwei oder zehn root-terminals öffnen kann - ganz wie er mag, ohne Password-Abfrage, weil Du das erlaubt hast.

Zum ersten Punkt ist allerdings anzumerken, dass das in etwa genau so sinnvoll ist, wie sein eigenes Bier zum Brauereibesuch mitzubringen. Man braucht diesen Umweg schlichtwewg nicht, man tut einfach das, was man will, auf direktem Wege.

Ich kann echt nicht glauben, wie es möglich ist, das die eigene Erwartungshaltung die Erkenntnis über die tatsächlich vorhandenen Möglichkeiten dieser Policy so erfolgreich verhindern kann. Du nutzt zudem auch noch Software aus Fremdquellen, eine Gewissheit darüber, dass Dein System noch wirklich intakt ist, hast Du definitiv nicht....aber egal... mach ruhig.

[TomL]

Bezüglich des Thread-Titels "Updates richtig machen" wäre die präziseste Antwort imho dann wohl:
Terminal öffnen > su –-login > Root-Passwort > apt update && apt full-upgrade && apt autoremove && apt autoclean

Das wäre wohl das technisch sauberste Vorgehen. Aber mir wäre das zu kompliziert und die Gefahr zu groß, dass die Anwender das wegen des Aufwands nicht mehr regelmäßig durchführen. Ausserdem beinhaltet das die Notwendigkeit, dass die Anwender das root-Passwd kennen müssen... und das kennt hier keiner, auf keinem System.

[rockyracoon]

@willy4711:

su -
oder
su -l
oder
su --login
statt. Alle 3 Kommandos sind identisch

Kannst dir aber noch einen weiteren Knoten in deinen Beine machen, und es "ganz korrekt" schreiben:

Ja, Nee.
Im Manpage-Text wird ja explizit gesagt, dass "su -" nicht genügt, sondern man sicherheitshalber "su --login" verwenden sollte.
Insofern sind "Deine" drei Befehlsvariationen sicher im Alltag eines normalen Desktop-Users ausreichend, aber sie sind eben nicht identisch.
Im übrigen beantrage ich hier im Forum den Titel des "Ober-Erbsenzählers". LOL.

@TomL:

Das wäre wohl das technisch sauberste Vorgehen.

Daaas wollte ich hören!

Aber mir wäre das zu kompliziert und die Gefahr zu groß, dass die Anwender das wegen des Aufwands nicht mehr regelmäßig durchführen. Ausserdem beinhaltet das die Notwendigkeit, dass die Anwender das root-Passwd kennen müssen... und das kennt hier keiner, auf keinem System.

Ich schreibe ja auch gefühlt in jedem 5. Beitrag, dass man sehr unterscheiden muß zwischen einem Desktop-Single-User-Zuhause und einem Firmennetz-Mitarbeiter mit beschränken Zugriffsrechten, wie ich es auch selbst die letzten 20 Jahre meiner Berufstätiglkeit als Angestellter erlebt hatte.
Auch gibt es imho signifikante Unterschiede im Linux-Vorwissen und den Support-Bedürfnissen zwischen einem Desktop-Single-User-Zuhause und einem Forenmitglied, welches Administrator eines professionellen Netzwerks ist.

Liebe Grüße an Euch und ernst gemeinten Dank für Eure regen und interessanten Postings.

[willy4711]

Willy, Du hast es offensichtlich immer noch nicht verstanden. Vor dem Hintergrund Deiner Policy ist es

völlig bedeutungslos, ob die Script-Attribute 555 sind, weil jeder unprivilegierte User jederzeit andere Attribute setzen kann, um dann die Datei beliebig zu ändern - ganz wie er mag, ohne Password-Abfrage, weil Du das erlaubt hast.

Code: Alles auswählen

root@XFCE:~# ls -al  /usr/local/bin/automaitc_update
-r-xr-xr-x 1 root root 136 Aug 14 16:45 /usr/local/bin/automaitc_update

und (hatte ich vergessen zu erwähnen)

Code: Alles auswählen

root@XFCE:~# lsattr /usr/local/bin/automaitc_update
----i---------e----- /usr/local/bin/automaitc_update

und als Root (su -):

Code: Alles auswählen

  GNU nano 4.9.3                     /usr/local/bin/automaitc_update                                
#!/bin/bash

pkexec xfce4-terminal -e "aptitude update"
pkexec xfce4-terminal -e "aptitude full-upgrade" 
geany /var/log/aptitude

exit

             [ Datei „/usr/local/bin/automaitc_update“ ist schreibgeschützt ]
^G Hilfe      ^O Speichern  ^W Wo ist     ^K Ausschneide^J Ausrichten ^C Cursor     M-U Rückgängig
^X Beenden    ^R Datei öffne^\ Ersetzen   ^U Text einfüg^T Rechtschr. ^_ Zu Zeile   M-E Wiederholen

Ich weiß wirklich nicht, wie man das machen soll.

Edit:
Selbst bei der
~/.config/package-update-indicator/package-update-indicator.conf


ist das "i" Attribut gesetzt, sodass sie als User nicht geändert werden kann.

Code: Alles auswählen

root@XFCE:~# rm /home/willy/.config/package-update-indicator/package-update-indicator.conf 
rm: das Entfernen von '/home/hans/.config/package-update-indicator/package-update-indicator.conf' ist nicht möglich: Die Operation ist nicht erlaubt

[willy4711]

@TomL:

Das wäre wohl das technisch sauberste Vorgehen.

Daaas wollte ich hören!

Hmm --- Dann haben wir wohl verschiedenen Manpages. Bei mir (man su) steht:

Code: Alles auswählen

-, -l, --login
              startet die Shell als Anmelde-Shell mit einer  Umgebung  ähnlich  zu
              einer realen Anmeldung:

                 o      löscht  alle  Umgebungsvariablen  außer TERM und jene, die
                        durch --whitelist-environment angegeben wurden.

                 o      initialisiert die Umgebungsvariablen  HOME,  SHELL,  USER,
                        LOGNAME und PATH.

                 o      wechselt in das Home-Verzeichnis des Zielbenutzers.

                 o      setzt  argv[0]  der  Shell  auf  »-«, um die Shell zur An‐
                        melde-Shell zu machen.

Das ist doch eindeutig ? oder ?

Was die erwähnten "Nebenwirkungen" betrifft habe ich keinen Beispiele und auch noch nie was von gehört.
Auch habe ich hier im Forum noch nicht gehört (gelesen), dass jemand von den alteingesessenen was andres als su -
verwendet.

[TomL]

Ich weiß wirklich nicht, wie man das machen soll.

Das ist mir völlig klar. Hier ein Beispiel, anstatt Deines Script manipuliere ich eine Datei in tmp.

Die Vorbereitungen, um eine Test-Datei zu erzeugen und mit den gleichen Rechten auszustatten, wie sie Dein Script hat. Btw, die dbus-Fehlermeldungen kannst Du ignorieren, das hatten wir ja schon, das hat nix mit den generellen Erlaubnissen durch das Polkit zu tun.

Code: Alles auswählen

thomas@xfce:/$ cd /tmp
thomas@xfce:/tmp$ pkexec xfce4-terminal -e "touch /tmp/testwilly"
thomas@xfce:/tmp$ pkexec xfce4-terminal -e "chmod 555 /tmp/testwilly"
thomas@xfce:/tmp$ pkexec xfce4-terminal -e "chattr +i /tmp/testwilly"

thomas@xfce:/tmp$ ls -lah /tmp/testwilly
-r-xr-xr-x 1 root root 0 Aug 15 15:28 /tmp/testwilly

thomas@xfce:/tmp$ lsattr /tmp/testwilly
----i---------e---- /tmp/testwilly

Wie Du siehst, hat die Datei exakt die gleichen Rechte, wie Dein Script.... und um das zu tun, war ich nicht ein einziges mal als "root" angemeldet oder habe ein root-Pwd eingegeben. Ich verwende als völlig unprivilegierter User nur den Generalschlüssel Deiner Policy.

Aber hier beginnt das Drama, hier beginnt das unbemerkt durchgeführte Illegale:

Code: Alles auswählen

thomas@xfce:/tmp$ pkexec xfce4-terminal -e "chattr -i /tmp/testwilly"
thomas@xfce:/tmp$ pkexec xfce4-terminal -e "chmod 777 /tmp/testwilly"

thomas@xfce:/tmp$ echo "hier lade ich jetzt willys klatsche aus dem web runter! hehehe" >/tmp/testwilly

thomas@xfce:/tmp$ pkexec xfce4-terminal -e "chmod 555 /tmp/testwilly"
thomas@xfce:/tmp$ pkexec xfce4-terminal -e "chattr +i /tmp/testwilly"

thomas@xfce:/tmp$ ls -lah /tmp/testwilly; lsattr /tmp/testwilly; cat /tmp/testwilly
-r-xr-xr-x 1 root root 62 Aug 15 15:43 /tmp/testwilly
----i---------e---- /tmp/testwilly
hier lade ich jetzt willys klatsche aus dem web runter! hehehe

Aufräumen:

Code: Alles auswählen

thomas@xfce:/tmp$ pkexec xfce4-terminal -e "chattr +i /tmp/testwilly"
thomas@xfce:/tmp$ pkexec xfce4-terminal -e "rm /tmp/testwilly"

Und wieder habe ich alle Änderungen durchgeführt, ohne ein einziges Mal ein root-Password einzugeben oder mich selber als root anzumelden. Ich habe alles als völlig unprivilegierter User durchgeführt. Wenn du es damit immer noch nicht verstehst, kann man das Problem leider nicht mehr lösen.

Hmm --- Dann haben wir wohl verschiedenen Manpages. Bei mir (man su) steht:

Lies oben im Absatz "Beschreibung".

[rockyracoon]

@willy4711:

Hmm --- Dann haben wir wohl verschiedenen Manpages. Bei mir (man su) steht:

-, -l, --login
startet die Shell als Anmelde-Shell mit einer Umgebung ähnlich zu
einer realen Anmeldung:

o löscht alle Umgebungsvariablen außer TERM und jene, die
durch --whitelist-environment angegeben wurden.

o initialisiert die Umgebungsvariablen HOME, SHELL, USER,
LOGNAME und PATH.

o wechselt in das Home-Verzeichnis des Zielbenutzers.

o setzt argv[0] der Shell auf »-«, um die Shell zur An‐
melde-Shell zu machen.

Das ist doch eindeutig ? oder ?

Nein, nicht eindeutig.
Und wir haben die gleiche Manpage. Weiter oben steht im Text, wie ich bereits gepostet habe:

Aus Es wird empfohlen, stets die Option --login (statt deren
Kurzform -) zu verwenden, um durch Mischen der Umgebungen verursachte
Nebenwirkungen zu vermeiden.

Nochmal: Nach der Manpage sind "su -" und "su --login" nicht identisch.
Daher beanspruche ich nach wie vor das Posting für "die sauberste Lösung" plus den Ehren-Titel "Ober-Erbsenzähler"!

[willy4711]

@TomL: Ich gebe mich geschlagen
Wenn ich mal Zeit und Lust habe, werde ich versuchen, die Geschichte auf das Skript und die Ausführung via Policy
zu reduzieren.
Zu deiner Beruhigung: Die Policy hatte ich schon vor ein paar Tagen geändert (auth_admin_keep).

Insofern war das ein sehr lehrreiches Scheingefecht.

[TomL]

@willy

[willy4711]

Nochmal: Nach der Manpage sind "su -" und "su --login" nicht identisch.

Sehe ich nicht so, da das in dem von mir zitieren Teil anders dargestellt wird.
Aber Vielleicht kannst du (oder jemand anderes) mir erklären, was ein

durch Mischen der Umgebungen verursachte
Nebenwirkungen

bedeuten soll, wenn alle 3 Varianten nach Manpage (mein zitierter Teil) dasselbe bewirken ?
Nämlich:

o löscht alle Umgebungsvariablen außer TERM und jene, die
durch --whitelist-environment angegeben wurden.

o initialisiert die Umgebungsvariablen HOME, SHELL, USER,
LOGNAME und PATH.

o wechselt in das Home-Verzeichnis des Zielbenutzers.

o setzt argv[0] der Shell auf »-«, um die Shell zur An‐
melde-Shell zu machen.

[rockyracoon]

Ich muß nichts erklären.
Der Satz:

Es wird empfohlen, stets die Option --login (statt deren
Kurzform -) zu verwenden, um durch Mischen der Umgebungen verursachte
Nebenwirkungen zu vermeiden.

Die Worte "stets ... zu verwenden" sind eindeutig und lassen keine Interpretationen zu.
Wie oft solche "Umgebungsmischungen" vorkommen und was das überhaupt ist, sei aber auch dahingestellt.
Oben habe ich Dir aber schon geschrieben, dass ich die drei von Dir zitierten su-Optionen ebenfalls für völlig ausreichend halte.
Es geht um das allerallerallerkorrekteste Vorgehen. Und darauf habe ich in Post gaaanz oben nur hinweisen wollen.

Also:
(1) perfetto:
su –-login > Root-Passwort > apt update && apt full-upgrade && apt autoremove && apt autoclean

(2) sufficiente:
su – > Root-Passwort > apt update && apt full-upgrade && apt autoremove && apt autoclean

[willy4711]

Ich muß und kann als DAU nichts erklären.
Immer wieder wird hier im Forum darauf hingewiesen, die Manpages zu lesen und zu beherzigen.

Na ja auch Manpages haben zuweilen Fehler oder sind teilweise überholt.

Deshalb würde ich halt gerne verstehen, was mit dieser oder jener Empfehlung gemeint sein könnte.
Oberflächlich habe ich bei allen Kommandos

Code: Alles auswählen

root@Sonstwas:~# 

Das sollte mir doch anzeigen dass ich mich im Root- Environment befinde?
In der ArchWiki wird su - z.B. gar nicht erwähnt.
Unterschiede in den Distributionen ?

Und das su –-login ist aus dieser Definition heraus dann ebenso unlogisch, weil es irgendetwas abkürzt.
Dann doch bitte

Code: Alles auswählen

su -l root  oder su --login root

Das wäre aus meinem Verständnis heraus dann konsequent.

Aber ........

[rockyracoon]

Meinen Beitrag oben:

Der Satz:

Es wird empfohlen, stets die Option --login (statt deren
Kurzform -) zu verwenden, um durch Mischen der Umgebungen verursachte
Nebenwirkungen zu vermeiden.

Die Worte "stets ... zu verwenden" sind eindeutig und lassen keine Interpretationen zu.
Wie oft solche "Umgebungsmischungen" vorkommen und was das überhaupt ist, sei aber auch dahingestellt.
Oben habe ich Dir aber schon geschrieben, dass ich die drei von Dir zitierten su-Optionen ebenfalls für völlig ausreichend halte.
Es geht um das allerallerallerkorrekteste Vorgehen. Und darauf habe ich in Post gaaanz oben nur hinweisen wollen.

Also:
(1) perfetto:
su –-login > Root-Passwort > apt update && apt full-upgrade && apt autoremove && apt autoclean

(2) sufficiente:
su – > Root-Passwort > apt update && apt full-upgrade && apt autoremove && apt autoclean

hast Du offensichtlich nicht gelesen, weil Du darauf keine Antwort gibst.

Kannst Du auch nicht, weil es da nichts zu rütteln gibt.
Der Sachverhalt ist so simpel wie eindeutig.

[willy4711]

hast Du offensichtlich nicht gelesen, weil Du darauf keine Antwort gibst.
Kannst Du auch nicht, weil es da nichts zu rütteln gibt.

Unachtsamkeit?
Tangentiale Kommunikation?

Retoure:

Aber Vielleicht kannst du (oder jemand anderes) mir erklären, was ein

durch Mischen der Umgebungen verursachte
Nebenwirkungen

bedeuten soll, wenn alle 3 Varianten nach Manpage (mein zitierter Teil) dasselbe bewirken ?

Habs schon gelesen, jedoch die Begründung für die "Empfehlung" nicht verstanden
Deshalb ist das für mich erstmal nicht nachvollziehbar.

Aber nun reicht es. Es sei denn, jemand bringt einen Erklärung, die ich mit meinem simplen Gemüt verstehe.

[rockyracoon]

@willy4711:

Habs schon gelesen, jedoch die Begründung für die "Empfehlung" nicht verstanden

Endlich eine Antwort, aufgrund deren man weiter diskutieren kann.

Wenn man eine Empfehlung einer Manpage nicht versteht, heißt das noch lange nicht, dass sie falsch oder unbegründet ist.
Das gilt auch für "release notes".
Und überhaupt habe ich von dem alleralleallerkorrektesten Vorgehen geschrieben.

[willy4711]

Wenn eine Empfehlung einer Manpage nicht verstanden wird, heißt das noch lange nicht, dass sie falsch oder unbegründet ist.

Na das ist aber dann genauso, wie mit den z.Z. üblichen Gesichtsmasken.

Und weg

[rockyracoon]

Und weg

Feigling.

Na das ist aber dann genauso, wie mit den z.Z. üblichen Gesichtsmasken.

Nach den Informationen die mir vorliegen, rate ich Dir dringend, eine Gesichtsmaske zu tragen und vor Allem gut Abstand in der Öffentlichkeit zu halten.
Die Wahrscheinlichkeit einer komplikativen Infektion ist von der Wahrscheinlichkeit her zwar (noch!) gering, sie kann aber auch junge vitale Menschen treffen und ist von den Folgen her - glaube mir - haarig, mit üblen Spätfolgen. Es geht nicht nur um Letalität, sondern auch um Invalidität. Dass Du nichts dergleichen erlebst, ist das Ergebnis verantwortungsvollen Seuchen-Managements mit überraschend guter Disziplin der Bevölkerung. Das sollte man nicht mit Leichtsinn verspielen. Dieser Virus ist neu, scheint viele "Tricks" drauf zu haben und sich nicht an die bisher bekannten "Spielregeln" zu halten.

Die Verquickung von Vorsicht beim Umgang mit dem PC mit dem Umgang mit der Gesundheit solltest Du nicht vornehmen. So einen Scheingefecht-Thread wie hier finde ich unterhaltsam. Einen PC kann ich neu kaufen. Ein System kann ich neu aufsetzen. Meine inneren Organe oder mein Gehirn kann ich aber nicht ersetzen. Bitte mache über das Thema keinen Ulk. Falls Du zweifelst, gehe zu einer Intensiv-Station und erlebe hautnah, was das der neue Virus anstellt. "Am besten" fähst Du in ein Dritte-Welt-Land, was keinen Schutz wie eine reiche Nation wie Deutschland vornehmen kann. Gehe dort in die Banlieues...

Wieder zum Thread-Thema:

Habs schon gelesen, jedoch die Begründung für die "Empfehlung" nicht verstanden

Die Ausführungen von TomL zu einem anderen Thema hast Du anfangs ja auch nicht verstanden.
Ich habe großen Respekt vor Deinem Linux-Fachwissen und lese viele Deiner Beiträge mit Interesse und Gewinn.
Manchmal bin ich aber regelrecht froh, nicht zu viel Linux-Wissen zu haben, was mich von unglücklichen "Experimenten" abhält.

Nochmal: Ich habe mit "su --login" von dem alleralleallerkorrektesten Vorgehen und selbstironisierend von "Erbsenzählerei" geschrieben.

[debianuser4782]

Nach dem Lesen einiger Beiträge in diesem Thread stellen sich mir nun folgende Fragen:
Besteht ein Risiko, wenn ich mich zu Hause auf der Console (tty) oder im Terminal als root einlogge und dann aus Bequemlichkeitsgründen bis zum Ende der Sitzung eingeloggt bleibe? Bei mir laufen iftop und journalctl -f als root während der ganzen Sitzung.

Ich sehe das nicht als Risiko. Es sind halt Prozesse, die mit root-Rechten laufen, fertig. Wobei das für das Journal eigentlich gar nicht notwendig ist. Wenn Du Dich in die Journal-Gruppe einträgst, solltest Du das auch als nicht-root lesen dürfen. Für iftop würde ich eine Policy erstellen, die Dir erlaubt, das Programm direkt mit 'pkexec iftop' als root zu starten. Solange dir keiner ein anderes iftop unterjubelt, kann man dabei vermutlich sogar das Password deaktivieren. Ich hätte da jetzt keine Bauchschmerzen.

Dies müsste doch eigentlich ein größeres "Risiko" darstellen als ein solch "offenes Terminal".

Nö, warum?

Und was ist eine root-shell? Sind damit bereits die Console oder das Terminal gemeint?

Eine root-Shell ist -so interpretiere ich das- eine Console (oder Terminal) in der root bereits angemeldet ist. Ist es ein vom User gestartetes Terminal, sehe ich das als normale unprivilegierte User-Shell, nach erfolgreichen su - wirds dann zur root-shell.

Tip: Wer nicht immer sein user- oder root-Passwort eintippen möchte

...erstellt sich eine Policiy.... sofern der Prozess eine isolierte Aufgabe hat und nicht dazu verwendet werden kann, das System oder die vorhandenen Rechteeinstellungen zu verändern. Einen Hardware-Key nehme ich beim Entschlüsseln meiner Reise-Laptop-Daten-Partition. Sicher, ich bin natürlich sehr vorsichtig, aber ich versuche auch nicht Paranoid zu sein. Und manchmal sind die Freiheiten, die ich mir selber gönne, nicht die gleichen, zu denen ich hier öffentlich rate *fg* Aber ich glaube, ich kann die Risiken meiner Freiheiten heute recht gut einschätzen.

Vielen Dank für die Erläuterungen. Ich werde mir PolicyKit und das Berechtigungssystem mal genauer anschauen.