- Bearbeitet
fdell Genau deshalb nutze ich Trizen, das nimmt mir die Arbeit mit den PKGbuilds ab. Das ist bei einzelnen AUR Paketen nicht notwendig, aber bei kompletten Systemupdates ist dieser Wrapper schon praktisch.
Das ist halt eine Frage/Diskussion über ein generelles Konzept. Ich persönlich trenne strikt das "System" (die Binärpakete, zertifiziert) von AUR-Paktet-Bauanleitungen (nicht binär, nicht zertifiziert, und: IMHO nicht wichtig für die Integrität/Funktionieren des Systems, mit Ausnahmen.)
Da beide "Quellen" für mich eben nicht gleichwertig sind, trenne ich beide strikt. Für mich muß erst das System-Update durchlaufen und funktionieren, der Paketmanager dazu ist pacman. Danach aktualisiere ich erst die (wenigen) AUR-"Pakete" die ich nutze, dafür habe ich einen AUR-Helper. Das stellt mir auch sicher, daß AUR-"Pakete" immer gegen den aktuellen Versionsstand des "Systems" ggf. kompiliert, gebaut, installiert werden.
AUR-"Pakete" haben für mich also einen "minderwertigen" Stellenwert, somit habe ich auch keinen Bedarf für einem "Manager", der diese Trennung nicht einhält bzw. ein Konzept, was diese Trennung "vermascht".
Anmerkungen zu deinem Updatekonzept:
Du legst ja offensichtlich einen Augenmerk auf "Sicherheit".
a) Bzgl. der Verwendung von sudo (egal ob nun für Root-Rechte oder wie im obigen für switch-user-Aktionen:
Mein Vorschlag wäre: Gewöhne dir an bei jedem sudo immer den vollen Pfad zum betroffenen Programm zu verwenden, sowohl beim Aufruf mittels sudo als auch beim Reglementieren von sudo-Aktionen(sudoers). Also sudo /usr/bin/trizen statt sudo trizen. Das ist ein Sicherheitskonzept.
Zu /root/upd_hosts.sh:
Ich würde das so machen:
#!/bin/bash
cd /tmp
wget https://winhelp2002.mvps.org/hosts.txt
head -40 hosts.txt | grep --quiet ^127.0.0.1
if (( $? != 0 )); then
echo "Error: Falsche hosts Download-Liste"
exit 1
else
cp hosts.txt /root/hosts.txt
fi
cat /root/hosts.txt /root/etc-hosts > /etc/hostsDas prüft den Downloadinhalt ob es wirklich die erwartete Liste (oder z.B. eine HTML-Fehlerseite) ist. Dafür werden die ersten 40 Zeilen nach dem Eintrag für localhost/127.0.0.1 durch sucht. Die Liste wird nur ins /root Dir kopiert wenn das zutrifft.
Danach wird aus beiden hosts-Dateien die reale direkt nach /etc geschrieben.
Selbst für den wget.Aufruf könnte man noch eine Auswertung bzgl. Erfolg/Fehler machen und das Skript ggf. abbrechen.
BTW: du hast gesehen, daß deine runtergeladene Hosts-Liste das anzeigt:
Updated: March-06-2021
//Edit:
Zum Post mit den Rechten bzw. wer Skripte wie starten kann.
Generell: Um ein Skript nach /usr/local/bin abzulegen bedarf es normalerweise Root-Rechte. Auch das ändern von Besitz/Gruppe und Berechtigungen bedarf Root-Rechte.
Skripte (also textuale Befehle die in irgendeinen Interpreter geladen und ausgeführt werden) weichen vom normalen Sicherheitskonzept für Binärcode mittels UNIX-Rechten ab. D.h. Eigenschaften von Besitzer/Gruppe und deren Rechte (rwx) gelten für die Frage: Wer führt diese Befehle aus? nur eingeschränkt.
Bsp:
[root@ws01 ~]# ls -l /tmp/wtf.sh && cat /tmp/wtf.sh
-rwxr--r-- 1 root root 35 24. Dez 10:49 /tmp/wtf.sh
#!/bin/bash
#
id
sudo /usr/bin/idAls root kann ich dieses Skript direkt ausführen(x) und ändern(w), als Normaluser nur lesen. Das sieht so aus:
[root@ws01 ~]# /tmp/wtf.sh
uid=0(root) gid=0(root) Gruppen=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),19(log)
uid=0(root) gid=0(root) Gruppen=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),19(log)Als Normaluser:
[ich@ws01 tmp]$ /tmp/wtf.sh
bash: /tmp/wtf.sh: Keine BerechtigungMir fehlen hier die Ausführungsrechte(x). Soweit, sogut. Aber:
Da ich die "Sammlung der Befehle" lesen kann (r), hindert mich nichts daran, diese Befehle direkt in den Interpreter(hier die bash, kann auch python, ruby, perl sein) zu laden:
[ich@ws01 tmp]$ sh /tmp/wtf.sh
uid=1001(ich) gid=1001(ich) Gruppen=1001(ich),10(wheel),93(optical),96(scanner),100(users),108(vboxusers)
[sudo] Passwort für ich:
uid=0(root) gid=0(root) Gruppen=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),19(log)Deshalb ist es wichtig, bei allen relevanten Skripten ganz am Anfang zu prüfen: Ist der aufrufende User wirklich derjenige, der die Befehle auch starten soll. Deshalb finden sich oft in Skripten anfangs die Prüfung: Ist die $UID == 0 (wenn es root sein soll), oder ist die $UID==1000 (wenn es ein bestimmter User sein soll)? Wenn Nein, dann breche hier sofort ab (exit 1 z.B.)
Alternativ kann anderen Usern die Leserechte entzogen werden:
[root@ws01 ~]# chmod o-r /tmp/wtf.sh && ls -l /tmp/wtf.sh
-rwxr----- 1 root root 35 24. Dez 10:49 /tmp/wtf.sh[ich@ws01 tmp]$ sh /tmp/wtf.sh
sh: /tmp/wtf.sh: Keine BerechtigungFür dein "Trizen" updatescript
fdell Mir wäre lieber wenn ich das Skript als normaler USER aufrufen kann und nur die notwendigen Befehle mit sudo als root aufrufen kann.
Dann müßte root das Skript IMHO so ablegen:
-rwx------ USER USERGRUPPE /usr/local/bin/updatescript
D.h. nur dein USER (und jeder andere der root-Rechte hat) kann dieses Skript direkt mit USER-Rechten direkt ausführen oder in einen Interpreter laden.
Das Skript selbst (wie ich schon mal schrieb: Zillionen von sudo-Aufrufen verlangen meist eine Konzeptänderung) könnte dann so aussehen:
#!/bin/sh
/usr/bin/trizen -Syyu
/usr/bin/trizen -Qneq | sort > /home/USER/infos/installierte-pakete/explicit-packages
/usr/bin/trizen -Qndq | sort > /home/USER/infos/installierte-pakete/depend-packages
/usr/bin/trizen -Qqem | sort > /home/USER/infos/installierte-pakete/aur-packages
sudo /root/upd_hosts.shBTW: Das Doppelt-y generell zu verwenden ist "schlechter Stil" da unnötig und eine Belastung der Spiegelserver.
Hier könntest du jetzt sicherheitshalber noch prüfen:
Gehört der Prozeß, der diese (Skript-)Befehle startet wirklich der UID von USER. Das wäre ein Sicherheitsgewinn.
