Wie installiert man manche selber compilierten Programme von NFS, wenn
die Makefiles bei make install lokale schreiben?

Meine Daten liegen komplett auf NFS. Sobald man da sudo macht, greift
root squash (was auch gut so ist) und man hat keine besonderen Rechte mehr.
Nun gibt es aber einige Programme, die bei "make install" trotzdem immer
wieder irgendwas neu schreiben wollen, auch wenn make gerade
durchgelaufen ist. Die kann man von einem NFS-Share aus nicht installieren.

Der einzige mir bekannte Ausweg ist alle Berechtigungen auf 777 zu
setzen, was natürlich üblicherweise nicht sinnvoll ist.
Geht das auch schöner?

Marcel

Am 20.04.24 um 17:33 schrieb Marcel Mueller:
> Wie installiert man manche selber compilierten Programme von NFS, wenn
> die Makefiles bei make install lokale schreiben?

Man benutzt make nicht auf NFS. :-P Es liegt wahrscheinlich an
den Timestamps. Mach Dir ein Overlay-FS, kompiliere in /tmp oder
/var oder was auch immer. Oder installiere irgendwo hin, wo Dein
normaler User Schreibrechte hat, so dass Du kein sudo brauchst.
Ich kannte einige Systeme (BSD?) wo eine Gruppe "operator"
Schreibrechte nach /usr/local hatte. Oder benutze

$ fakeroot <<EOT | sudo tar -vxC /
> make DESTDIR=/tmp/whatever install >&2
> tar -cC /tmp/whatever .
> EOT

(Vorsicht, im Newsreader "programmiert". Besser erstmal mit
temporärem Archiv testen, ohne Pipe.)

MfG

Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:

> Meine Daten liegen komplett auf NFS. Sobald man da sudo macht, greift
> root squash (was auch gut so ist) und man hat keine besonderen Rechte mehr.
> Nun gibt es aber einige Programme, die bei "make install" trotzdem immer
> wieder irgendwas neu schreiben wollen, auch wenn make gerade
> durchgelaufen ist. Die kann man von einem NFS-Share aus nicht installieren.

Das klingt so, als würdest Du "make install" in der Regel als root
aufrufen? Warum das denn? Ich installiere Software als normaler User.
Was ich selbst compiliere, kommt natürlich nicht nach /usr, das
"gehört" dem System, sondern nach z.B. /usr/local (oder wo auch immer,
jedenfalls außerhalb der Bereiche, wo das System dran rumfummelt).

Nur so ein Gedanke ... Andreas

Am 20.04.24 um 20:32 schrieb Andreas M. Kirchwitz:
> Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:
>
>> Meine Daten liegen komplett auf NFS. Sobald man da sudo macht, greift
>> root squash (was auch gut so ist) und man hat keine besonderen Rechte mehr.
>> Nun gibt es aber einige Programme, die bei "make install" trotzdem immer
>> wieder irgendwas neu schreiben wollen, auch wenn make gerade
>> durchgelaufen ist. Die kann man von einem NFS-Share aus nicht installieren.
>
> Das klingt so, als würdest Du "make install" in der Regel als root
> aufrufen? Warum das denn? Ich installiere Software als normaler User.
> Was ich selbst compiliere, kommt natürlich nicht nach /usr, das
> "gehört" dem System, sondern nach z.B. /usr/local (oder wo auch immer,
> jedenfalls außerhalb der Bereiche, wo das System dran rumfummelt).

Das geht alles nach /usr/local. Aber dazu braucht man auch root-Rechte.
Anders könnte ja jedes Userspace-Programm beliebigen Code in
Standardprogramme injizieren, indem es die Priorität der /usr/local
Pfade nutzt.

Marcel

Am 21.04.24 um 11:20 schrieb Marcel Mueller:

> Das geht alles nach /usr/local. Aber dazu braucht man auch root-Rechte.
> Anders könnte ja jedes Userspace-Programm beliebigen Code in
> Standardprogramme injizieren, indem es die Priorität der /usr/local
> Pfade nutzt.

Wenn man das so macht, sollte /usr/local/bin tatsächlich nach
/usr/bin im Pfad kommen.

MfG

Am 20.04.24 um 18:50 schrieb Markus Schaaf:
> Am 20.04.24 um 17:33 schrieb Marcel Mueller:
>> Wie installiert man manche selber compilierten Programme von NFS, wenn
>> die Makefiles bei make install lokale schreiben?
>
> Man benutzt make nicht auf NFS. :-P

Was anderes sinnvolles habe ich nicht. Nur davon gibt es Backups. Und
die lokalen Rechner oder VMs haben zum Teil so gut wie keinen Storage.
Der aktuell hat z.B. 40GB. Die VMs liegen in derselben Größenordnung.

> Es liegt wahrscheinlich an den
> Timestamps.

Nein, die sind in Ordnung. Es gibt einfach Makefiles, die immer
irgendwas schreiben.
Bei den meisten funktioniert es, wenn vorher alles gebaut war und root
wenigstens Leserechte hat. Damit kann ich leben, ist eh alles OSS.

> Mach Dir ein Overlay-FS, kompiliere in /tmp oder /var oder
> was auch immer.

Könnte eng werden. Aber ja, das dürfte gehen.

> Oder installiere irgendwo hin, wo Dein normaler User
> Schreibrechte hat, so dass Du kein sudo brauchst.

Das ist halt immer ein Risiko, zumindest, wenn es im Pfad drin ist.

> Ich kannte einige
> Systeme (BSD?) wo eine Gruppe "operator" Schreibrechte nach /usr/local
> hatte.

Das könnte ich natürlich einrichten, aber eben nur mit o.g. Risiko.

> Oder benutze
>
> $ fakeroot <<EOT | sudo tar -vxC /
> > make DESTDIR=/tmp/whatever install >&2
> > tar -cC /tmp/whatever .
> > EOT
>
> (Vorsicht, im Newsreader "programmiert". Besser erstmal mit temporärem
> Archiv testen, ohne Pipe.)

Das habe ich jetzt nicht verstanden. Was macht das fakeroot da? Und
wieso steht kein Befehl vor der Pipe?

Marcel

Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:

> Das geht alles nach /usr/local. Aber dazu braucht man auch root-Rechte.

Nein, ganz bestimmt nicht, dafür braucht man keine root-Rechte,
höchstens für sehr seltene Ausnahmen, wo ein Binary setuid root
installiert werden möchte, aber so was kann man auch noch später
von Hand nachholen und die Hauptinstallation ohne root machen.

> Anders könnte ja jedes Userspace-Programm beliebigen Code in
> Standardprogramme injizieren, indem es die Priorität der /usr/local
> Pfade nutzt.

Häh? Wo ist der Unterschied, ob User X seine selbstcompilierte
Software in /usr/local unter seiner eigenen User-ID installiert
oder ob er sich vorher root-Rechte holt? Das ändert doch abgesehen
vom Eigentümer nichts an den Dateien in /usr/local.

Vor allem ist es ein großes Risiko, wenn jeder User immer gleich
root-Rechte benötigt, bloß um zusätzliche Software bereitzustellen.

Vertrauen zur Installation von zusätzlicher Software ist die eine
Sache, das ganze Basissystem zu verändern, ist eine andere Sache.

Natürlich erhält in /usr/local nur eine Gruppe von Usern Zugriff,
denen man hinreichend vertraut. Dafür gibt's unter Unix ja die
Gruppen, die merkwürdigerweise von vielen Admins verschmäht werden.

Vor allem fällt mit dieser Methode auch sofort auf, wenn eine
Software versucht, außerhalb von /usr/local herumzufummeln,
wo sie in der Regel nichts zu suchen hat.

Grüße, Andreas

Am 21.04.24 um 12:21 schrieb Andreas M. Kirchwitz:
> Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:
>
>> Das geht alles nach /usr/local. Aber dazu braucht man auch root-Rechte.
>
> Nein, ganz bestimmt nicht, dafür braucht man keine root-Rechte,

Also bei Debian, Ubuntu und Mint schon.

>> Anders könnte ja jedes Userspace-Programm beliebigen Code in
>> Standardprogramme injizieren, indem es die Priorität der /usr/local
>> Pfade nutzt.
>
> Häh? Wo ist der Unterschied, ob User X seine selbstcompilierte
> Software in /usr/local unter seiner eigenen User-ID installiert
> oder ob er sich vorher root-Rechte holt? Das ändert doch abgesehen
> vom Eigentümer nichts an den Dateien in /usr/local.

Wenn ich als User etwas compiliere, dann kann ich es nur nach ~/bin
packen und dort steht es nur bei mir selbst im Pfad.

In /usr/local hingegen kann ich darauf warten, dass ein anderer User,
vorzugsweise root in die Falle tappt und mein Programm ausführt.
Das ist im Prinzip derselbe Angriffsvektor, wie wenn man unter Windows
eine gepatchte MSVCRT.DLL in allen möglichen Verzeichnissen fallen
lässt, und darauf wartet, dass irgendjemand sie versehentlich lädt (geht
mittlerweile nicht mehr).

> Vor allem ist es ein großes Risiko, wenn jeder User immer gleich
> root-Rechte benötigt, bloß um zusätzliche Software bereitzustellen.

Tja, abgestufter geben es die alten Unix-Standards nicht her. Zwischen
User und Root gibt es bei den meisten Distributionen nicht viel, und
wenn dann nur sehr punktuell, z.B. für Drucker-Administration.

> Vertrauen zur Installation von zusätzlicher Software ist die eine
> Sache, das ganze Basissystem zu verändern, ist eine andere Sache.

Zusätzlich ist ein relativer Begriff. Üblicherweise ist /usr/local vor
/usr in den Pfaden, damit selber compilierte Versionen von irgendetwas
Priorität haben.

> Natürlich erhält in /usr/local nur eine Gruppe von Usern Zugriff,
> denen man hinreichend vertraut.

Damit entfällt halt die notwendige Passworteingabe bei sudo. Was
wiederum bedeutet, eventuell kompromittierte Software kann unbemerkt
agieren.

> Dafür gibt's unter Unix ja die
> Gruppen, die merkwürdigerweise von vielen Admins verschmäht werden.

Es bräuchte schon einen anderen User, der dort und gleichzeitig im
Source-Verzeichnis schreiben darf. Dann könnte man mit su zu diesem
wechseln und die Installation vornehmen. Etwas umständlich, aber ich
denke darüber nach.

> Vor allem fällt mit dieser Methode auch sofort auf, wenn eine
> Software versucht, außerhalb von /usr/local herumzufummeln,
> wo sie in der Regel nichts zu suchen hat.

?

Marcel

Am 21.04.24 um 11:40 schrieb Marcel Mueller:

>> Mach Dir ein Overlay-FS, kompiliere in /tmp oder /var oder
>> was auch immer.
>
> Könnte eng werden. Aber ja, das dürfte gehen.

Mit Overlay-FS brauchst Du doch nur die paar kB/MB, die
geschrieben werden. Das kannst Du zur Not in Tmp-FS im RAM haben.

>> Oder installiere irgendwo hin, wo Dein normaler User
>> Schreibrechte hat, so dass Du kein sudo brauchst.
>
> Das ist halt immer ein Risiko, zumindest, wenn es im Pfad drin ist.

Wie schon woanders geschrieben: Wenn man /usr/local für
nicht-Root freigibt, kommt es natürlich nach /usr im Pfad.

>> Oder benutze
>>
>> $ fakeroot <<EOT | sudo tar -vxC /
>> > make DESTDIR=/tmp/whatever install >&2
>> > tar -cC /tmp/whatever .
>> > EOT
>>
>> (Vorsicht, im Newsreader "programmiert". Besser erstmal mit temporärem
>> Archiv testen, ohne Pipe.)
>
> Das habe ich jetzt nicht verstanden. Was macht das fakeroot da? Und
> wieso steht kein Befehl vor der Pipe?

Fakeroot steht vor der Pipe. Fakeroot gibt Dir eine Shell, in der
es so aussieht, als wärest Du Root. Damit installierst Du die
Software in ein temporäres Basisverzeichnis (mit DESTDIR),
erstellst ein Tar-Archiv, in dem alle Owner und Rechte stimmen.
Das kannst Du dann mit sudo entpacken.

$ tmpdir=/tmp/blah
$ mkdir -p $tmpdir && cd $tmpdir
$ fakeroot
# whoami
root
# touch test
# ls -l
insgesamt 0
-rw-r--r-- 1 root root 0 21. Apr 16:01 test
# exit
$ ls -l
insgesamt 0
-rw-r--r-- 1 mschaaf mschaaf 0 21. Apr 16:01 test
$

MfG

Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:

>>> Das geht alles nach /usr/local. Aber dazu braucht man auch root-Rechte.
>>
>> Nein, ganz bestimmt nicht, dafür braucht man keine root-Rechte,
>
> Also bei Debian, Ubuntu und Mint schon.

Ganz sicher nicht, definitiv nicht.

>> Häh? Wo ist der Unterschied, ob User X seine selbstcompilierte
>> Software in /usr/local unter seiner eigenen User-ID installiert
>> oder ob er sich vorher root-Rechte holt? Das ändert doch abgesehen
>> vom Eigentümer nichts an den Dateien in /usr/local.
>
> Wenn ich als User etwas compiliere, dann kann ich es nur nach ~/bin
> packen und dort steht es nur bei mir selbst im Pfad.

Wenn der Admin Dir nicht traut, dann mag das so sein.

> In /usr/local hingegen kann ich darauf warten, dass ein anderer User,
> vorzugsweise root in die Falle tappt und mein Programm ausführt.

Was lässt Du für merkwürdige User auf Deine Systeme,
die nur darauf warten, Dich zu hacken?

Den gesamten Baum in /usr/local kann man einer Unix-Gruppe geben,
nennen wir sie einfach "local", und dort können dann Leute, die
für alle Software installieren sollen, mit User-Rechten Software
compilieren und installieren. Möglicherweise sind das User, denen
man auch root-Rechte gegeben hätte, doch das muss nicht zwingend
so sein, aber in jedem Fall muss dort niemand unnötig als root
etwas machen, was auch mühelos als normaler User geht.

Software sollte man nicht vertrauen, dass sie beim Compilieren
oder Installieren alles richtig macht. Da gibt auch manchmal
welche, die das gesamte System in Schutt und Asche gelegt hätte.
Dagegen ist es ein guter Schutz, eben nicht mit root-Rechten
Software zu compilieren oder zu installieren.

Wer das nicht in /usr/local machen will, kann auch was in /opt
nehmen oder sonst wo auf dem System, ist ja egal, denn /usr/local
hat im Grunde keine besondere Bedeutung, außer dass es oft der
Default ist für selbstcompilierte Software.

>> Vor allem ist es ein großes Risiko, wenn jeder User immer gleich
>> root-Rechte benötigt, bloß um zusätzliche Software bereitzustellen.
>
> Tja, abgestufter geben es die alten Unix-Standards nicht her.

Doch, es gibt Gruppen. Nutzt kaum noch jemand, sind aber geil.

> Zwischen
> User und Root gibt es bei den meisten Distributionen nicht viel, und
> wenn dann nur sehr punktuell, z.B. für Drucker-Administration.

Gruppen werden von den meisten Distributionen tatsächlich genutzt
für die Lücke zwischen root und User.

>> Vertrauen zur Installation von zusätzlicher Software ist die eine
>> Sache, das ganze Basissystem zu verändern, ist eine andere Sache.
>
> Zusätzlich ist ein relativer Begriff. Üblicherweise ist /usr/local vor
> /usr in den Pfaden, damit selber compilierte Versionen von irgendetwas
> Priorität haben.

Natürlich ist das so, aber man lässt ja auch nicht jeden User
in /usr/local Software installieren, so wie man auch nicht
jedem User root-Rechte gibt. Es gibt aber eine Welt dazwischen,
die man mit Unix-Bordmitteln leicht steuern kann.

>> Natürlich erhält in /usr/local nur eine Gruppe von Usern Zugriff,
>> denen man hinreichend vertraut.
>
> Damit entfällt halt die notwendige Passworteingabe bei sudo. Was
> wiederum bedeutet, eventuell kompromittierte Software kann unbemerkt
> agieren.

Ich verstehe, was Du damit sagen willst, aber was soll das
in der Realität tatsächlich bringen? Das Risiko, mit root zu
hantieren, ist um Größenordnungen höher.

>> Dafür gibt's unter Unix ja die
>> Gruppen, die merkwürdigerweise von vielen Admins verschmäht werden.
>
> Es bräuchte schon einen anderen User, der dort und gleichzeitig im
> Source-Verzeichnis schreiben darf. Dann könnte man mit su zu diesem
> wechseln und die Installation vornehmen. Etwas umständlich, aber ich
> denke darüber nach.

Das ist sehr umständlich, aber wenn es für Dich seinen Zweck
erfüllt, freue ich mich. :-)

>> Vor allem fällt mit dieser Methode auch sofort auf, wenn eine
>> Software versucht, außerhalb von /usr/local herumzufummeln,
>> wo sie in der Regel nichts zu suchen hat.
>
> ?

Bei "make install" gibt es trotz anderslautender Optionen manches
Softwarepaket, was trotzdem direkt in z.B. /etc oder /usr fummeln
möchte. Das kann einem das System zerlegen. :-(

Daher installiere ich grundsätzlich nicht mit root-Rechten, außer
wenn ich weiß, dass es aus technischen Gründen schwerlich anders
geht und ich vorher genau geprüft habe, was im Makefile steht.
Diese Risiko, dass "make install" mein System zerstört, das ist
leider real und eine tatsächliche Gefahr, die es aktiv abzuwenden
gilt.

Grüße, Andreas

Markus Schaaf <mschaaf@elaboris.de> wrote:

> Wie schon woanders geschrieben: Wenn man /usr/local für
> nicht-Root freigibt, kommt es natürlich nach /usr im Pfad.

Das würde dem Sinn widersprechen, dass /usr/local üblicherweise
bewusst die vorinstallierte Standard-Software ausstechen soll,
und glücklicherweise ist es aber auch nicht notwendig, für das
Werkeln in /usr/local gleich root-Rechte haben zu müssen, obwohl
es freilich oft Leute sind, die root-Rechte erlangen könnten,
wenn sie es müssten, jedoch funktioniert /usr/local auch ohne,
sofern man schon mal von Unix-Gruppen gehört hat.

Grüße, Andreas

Am 21.04.24 um 16:40 schrieb Andreas M. Kirchwitz:
> Markus Schaaf <mschaaf@elaboris.de> wrote:
>
>> Wie schon woanders geschrieben: Wenn man /usr/local für
>> nicht-Root freigibt, kommt es natürlich nach /usr im Pfad.
>
> Das würde dem Sinn widersprechen, dass /usr/local üblicherweise
> bewusst die vorinstallierte Standard-Software ausstechen soll,

Das macht man besser mit "alias" und "rpath" beim Linken (macht
viele Software automatisch, wenn sie Libraries außerhalb /usr/lib
installiert) oder zur Not LD_LIBRARY_PATH in der .bashrc o.ä. --
Sonst gibst Du im Prinzip allen, die /usr/local schreiben können,
Vollzugriff auf Deine Dateien.

MfG

Markus Schaaf <mschaaf@elaboris.de> wrote:

>>> Wie schon woanders geschrieben: Wenn man /usr/local für
>>> nicht-Root freigibt, kommt es natürlich nach /usr im Pfad.
>>
>> Das würde dem Sinn widersprechen, dass /usr/local üblicherweise
>> bewusst die vorinstallierte Standard-Software ausstechen soll,
>
> Das macht man besser mit "alias" und "rpath" beim Linken (macht
> viele Software automatisch, wenn sie Libraries außerhalb /usr/lib
> installiert) oder zur Not LD_LIBRARY_PATH in der .bashrc o.ä. --

Äh, warum installiert man dann überhaupt etwas in /usr/local,
wenn man es keiner nutzt, weil man dem Bereich nicht traut?

> Sonst gibst Du im Prinzip allen, die /usr/local schreiben können,
> Vollzugriff auf Deine Dateien.

Ich gebe täglich hunderten von Leuten Zugriff auf meine Dateien,
die Software für meine Unix-Distribution erstellen. Diese Leute
kenne ich noch nicht mal. Habe sie nie gesehen. Sie wechseln
sogar ständig, ohne dass ich etwas davon mitbekomme. Und wie sich
bei xz gezeigt hat, sollte man ihnen vielleicht tatsächlich nicht
pauschal vertrauen.

Wer in /usr/local schreiben kann, den sucht sich der Admin aus,
und zwar jede Person einzeln. Wenn ich dem Admin nicht traue,
kann ich dem gesamten System nicht trauen. Wenn ich dem Admin
traue, dann auch seiner Einschätzung, wer in /usr/local werkeln
darf. Oftmals sind das übrigens ebenfalls Admins, die ohnehin
root-Rechte haben. Bloß dass es eben superdumm ist, ohne Not
mit root-Rechten zu arbeiten, und für vernünftig aufgesetztes
/usr/local braucht man glücklicherweise keine root-Rechte.

Grüße, Andreas

Am 21.04.24 um 18:28 schrieb Andreas M. Kirchwitz:

> /usr/local braucht man glücklicherweise keine root-Rechte.

Weil bei Dir jeder, der dort schreiben kann, Root ist. Kannst Du
machen. Kenne Deine Umstände nicht. Ich installiere nicht mal
meine eigene Software mit "make install". Geht alles über den
Paketmanager, internes Repository, das Audit-Log usw., die Pakete
können auch nach dem Deinstallieren noch untersucht werden, weil
sie im Cache bleiben. -- Ich habe das allerdings früher auch
beruflich für Firmen gemacht. Und habe mir schon Wochenenden um
die Ohren geschlagen, um ganze Abteilungen nach Virusbefall neu
zu installieren. Anderer Blickwinkel. Wissen schon.

MfG

Markus Schaaf <mschaaf@elaboris.de> wrote:

>> /usr/local braucht man glücklicherweise keine root-Rechte.
>
> Weil bei Dir jeder, der dort schreiben kann, Root ist.

Nein, keineswegs, sondern das sind in erster Linie Leute,
denen man soweit vertraut, dass sie verstehen, was /usr/local
für eine Bedeutung hat, nicht mehr, nicht weniger.

Manche können unabhängig davon vielleicht auch root-Rechte
haben, vielleicht wenn es um den Betrieb von Diensten geht.
Umgekehrt muss jedoch nicht jeder mit root-Rechten ein
Verständnis dafür haben, wie ein gutes /usr/local aussieht.

Je mehr User auf dem System sind, desto mehr gehen diese
Gruppen üblicherweise auseinander.

Kann ja am Ende jeder so machen, wie er möchte, und mein
einziger Punkt hier war, dass es für "make install" und
/usr/local keinen gottgegebenen root-Zwang gibt, sondern
das funktioniert auch prima ohne und ist vertrauenswürdig.
Ja, geht definitiv. Wenn man möchte. :-)

Grüße, Andreas

Am 21.04.24 um 16:32 schrieb Andreas M. Kirchwitz:
> Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:
>
>>>> Das geht alles nach /usr/local. Aber dazu braucht man auch root-Rechte.
>>>
>>> Nein, ganz bestimmt nicht, dafür braucht man keine root-Rechte,
>>
>> Also bei Debian, Ubuntu und Mint schon.
>
> Ganz sicher nicht, definitiv nicht.

Ich habe nicht eine Installation gefunden, wo /usr/local nicht root:root
mit 755 ist.

>>> Häh? Wo ist der Unterschied, ob User X seine selbstcompilierte
>>> Software in /usr/local unter seiner eigenen User-ID installiert
>>> oder ob er sich vorher root-Rechte holt? Das ändert doch abgesehen
>>> vom Eigentümer nichts an den Dateien in /usr/local.
>>
>> Wenn ich als User etwas compiliere, dann kann ich es nur nach ~/bin
>> packen und dort steht es nur bei mir selbst im Pfad.
>
> Wenn der Admin Dir nicht traut, dann mag das so sein.

Das ist nicht der Punkt. sudo verlangt nach einer Passworteingabe, und
das ist ein Aufmerksamkeitsmoment. Mit Gruppenrechten ist es ohne
Rückfrage, d.h. jedes Programm könnte es auf gut Glück mal versuchen.

>> In /usr/local hingegen kann ich darauf warten, dass ein anderer User,
>> vorzugsweise root in die Falle tappt und mein Programm ausführt.
>
> Was lässt Du für merkwürdige User auf Deine Systeme,
> die nur darauf warten, Dich zu hacken?

Eher welche Software, die man installiert hat und die ein
Sicherheitsproblem hat. Jedenfalls taugt schreibbares /usr/local für
eine stille Ausweitung der Benutzerrechte. Das nennt man Privilege
Escalation Vulnerability. Das brauche ich nicht.

> Wer das nicht in /usr/local machen will, kann auch was in /opt
> nehmen oder sonst wo auf dem System, ist ja egal, denn /usr/local
> hat im Grunde keine besondere Bedeutung, außer dass es oft der
> Default ist für selbstcompilierte Software.

.... und in sämtlichen Pfaden drin ist, was spätestens bei Shared
Libraries ziemlich essentiell ist.

>>> Vor allem ist es ein großes Risiko, wenn jeder User immer gleich
>>> root-Rechte benötigt, bloß um zusätzliche Software bereitzustellen.
>>
>> Tja, abgestufter geben es die alten Unix-Standards nicht her.
>
> Doch, es gibt Gruppen. Nutzt kaum noch jemand, sind aber geil.

Nutze ich schon, aber nicht an der Stelle.

>> Zwischen
>> User und Root gibt es bei den meisten Distributionen nicht viel, und
>> wenn dann nur sehr punktuell, z.B. für Drucker-Administration.
>
> Gruppen werden von den meisten Distributionen tatsächlich genutzt
> für die Lücke zwischen root und User.

Da bringt es halt nichts, weil man Gruppen im Gegensatz zu root keinen
sudo-Zwang auferlegen kann. Man bräuchte dann einen zusätzlichen,
partiell privilegierten User, der man erst werden muss. Der zu werden
gibt sudo aber AFAIK nicht her.

>>> Natürlich erhält in /usr/local nur eine Gruppe von Usern Zugriff,
>>> denen man hinreichend vertraut.
>>
>> Damit entfällt halt die notwendige Passworteingabe bei sudo. Was
>> wiederum bedeutet, eventuell kompromittierte Software kann unbemerkt
>> agieren.
>
> Ich verstehe, was Du damit sagen willst, aber was soll das
> in der Realität tatsächlich bringen? Das Risiko, mit root zu
> hantieren, ist um Größenordnungen höher.

Nein, da es um Größenordnungen seltener stattfindet.
Der normale User bin ich immer, und jedes gestartete Programm hat diese
Rechte. Bei meinen virtuellen Desktops ist das 24/7. Die schaltet keiner
ab, warum auch? 1W zusätzlicher Verbrauch des Servers ist egal.
Root bin ich nur für Sekunden und dabei laufen auch nur sehr wenige
Programme.
Im ersteren Fall hingegen reicht ein kompromittiertes Office-Dokument
und eine Buffer-Overflow in irgendeine Library, für Bilder, Kompression
oder was auch immer.

>> Es bräuchte schon einen anderen User, der dort und gleichzeitig im
>> Source-Verzeichnis schreiben darf. Dann könnte man mit su zu diesem
>> wechseln und die Installation vornehmen. Etwas umständlich, aber ich
>> denke darüber nach.
>
> Das ist sehr umständlich, aber wenn es für Dich seinen Zweck
> erfüllt, freue ich mich. :-)

Eben. Umständlich.

Tatsächlich ist das der Weg, den man im professionellen Bereich bei
Admins wärmstens empfiehlt, wenn man nicht jedem Hacker Tür und Tor
öffnen will. Jeder User hat mindestens zwei verschiedene Accounts mit
unterschiedlichen Rechten und auch unterschiedlichen Passwörtern -
letztere Bedingung erfüllt der sudo-Ansatz nicht.

Könnte man sudo eigentlich beibringen, etwas anderes als root zu werden?
Dann könnte ich eine Regel für "make install" erstellen, die auf einen
anderen User geht, der das nötige darf. Eine Develop-Gruppe habe ich
sowieso. Der User würde dann halt noch zusätzlich LocalInstall oder so
bekommen. Und /usr/local tackere ich per s-Flag auf die Gruppe fest.

> Bei "make install" gibt es trotz anderslautender Optionen manches
> Softwarepaket, was trotzdem direkt in z.B. /etc oder /usr fummeln
> möchte. Das kann einem das System zerlegen. :-(

Klar, das kann immer passieren. Aber ich installieren ja auch nur sehr
wenige Anwendungen selbst. Meist Zeug, was ohnehin im Repository ist,
ich aber Patches oder Erweiterungen am Code mache.

> Daher installiere ich grundsätzlich nicht mit root-Rechten, außer
> wenn ich weiß, dass es aus technischen Gründen schwerlich anders
> geht und ich vorher genau geprüft habe, was im Makefile steht.
> Diese Risiko, dass "make install" mein System zerstört, das ist
> leider real und eine tatsächliche Gefahr, die es aktiv abzuwenden
> gilt.

Das habe ich tatsächlich noch nicht geschafft.
Aber ich kenne durchaus Kandidaten, die mehr als nur das Zeug dazu
hatten. Unvergessen die ersten Versionen von PiHole, die von wget direkt
in die root-Shell gepipt haben. Sowas geht gar nicht.

Üblicherweise würde es aber auch nur eine VM erwischen. Am Server spiele
ich so wenig wie möglich herum. Und das so viele Jahre bis der
Supportzeitraum wirklich am Ende ist. Das sind dann wenigstens 5 Jahre.

Marcel

Am 21.04.2024 um 11:40 schrieb Marcel Mueller:
> Am 20.04.24 um 18:50 schrieb Markus Schaaf:
>> Am 20.04.24 um 17:33 schrieb Marcel Mueller:
>>> Wie installiert man manche selber compilierten Programme von NFS, wenn
>>> die Makefiles bei make install lokale schreiben?
>>
>> Man benutzt make nicht auf NFS. :-P
>
> Was anderes sinnvolles habe ich nicht. Nur davon gibt es Backups. Und
> die lokalen Rechner oder VMs haben zum Teil so gut wie keinen Storage.
> Der aktuell hat z.B. 40GB. Die VMs liegen in derselben Größenordnung.

Von den Objektdateien brauchst du hoffentlich keine Backups, die kannst
du doch jederzeit regenerieren.

Wenn die Makefiles keinen out-of-tree-Build können, wäre das zu ändern
nervige, aber gut investierte Arbeit.

>> Oder benutze
>>
>> $ fakeroot <<EOT | sudo tar -vxC /
>>  > make DESTDIR=/tmp/whatever install >&2
>>  > tar -cC /tmp/whatever .
>>  > EOT
>>
>> (Vorsicht, im Newsreader "programmiert". Besser erstmal mit temporärem
>> Archiv testen, ohne Pipe.)
>
> Das habe ich jetzt nicht verstanden. Was macht das fakeroot da? Und
> wieso steht kein Befehl vor der Pipe?

Dem "make install" und insb. dem "tar c" vorgaukeln, es hätte root-Rechte.

Alternativ geht etwas ähnliches mit "unshare". Damit kannst du dir einen
eigenen Namespace bauen, in dem du root bist, womit insb. "mount --bind"
und "chroot" funktionieren.

Aber am Ende sollte zumindest bei Programmen ohne zu komplizierte
Dateirechte das "make DESTDIR=.... install" auch so funktionieren.

Stefan

Am 22.04.24 um 18:54 schrieb Marcel Mueller:

> Das ist nicht der Punkt. sudo verlangt nach einer Passworteingabe, und
> das ist ein Aufmerksamkeitsmoment. Mit Gruppenrechten ist es ohne
> Rückfrage, d.h. jedes Programm könnte es auf gut Glück mal versuchen.

Auch Gruppen können Passworte haben. Allerdings kenne ich kein
Tool, mit dem man das ähnlich leicht setzen könnte wie mit
passwd(1). Man muss das verschlüsselte Passwort selbst in
gshadow(5) eintragen, oder groupmod -p benutzen. Hilfsweise
könnte man einen Dummy-User anlegen, ein Passwort setzen, und
dann von shadow(5) nach gshadow(5) kopieren.

> Da bringt es halt nichts, weil man Gruppen im Gegensatz zu root keinen
> sudo-Zwang auferlegen kann. Man bräuchte dann einen zusätzlichen,
> partiell privilegierten User, der man erst werden muss. Der zu werden
> gibt sudo aber AFAIK nicht her.

$ sudo -u <user> [-g <group>]
$ man sudo

>> Bei "make install" gibt es trotz anderslautender Optionen manches
>> Softwarepaket, was trotzdem direkt in z.B. /etc oder /usr fummeln
>> möchte. Das kann einem das System zerlegen. :-(
>
> Klar, das kann immer passieren. Aber ich installieren ja auch nur sehr
> wenige Anwendungen selbst. Meist Zeug, was ohnehin im Repository ist,
> ich aber Patches oder Erweiterungen am Code mache.

Das ist noch ein Vorteil von fakeroot + DESTDIR + tar: Du kannst
das Tar-File (oder DESTDIR, vor dem einpacken) mit "tar -tf
<file> | less" inspizieren. Und dann z.B. ungewünschte Teile
ausschließen.

MfG

Markus Schaaf <mschaaf@elaboris.de> wrote:
> Am 22.04.24 um 18:54 schrieb Marcel Mueller:

> > Das ist nicht der Punkt. sudo verlangt nach einer Passworteingabe, und
> > das ist ein Aufmerksamkeitsmoment. Mit Gruppenrechten ist es ohne
> > Rückfrage, d.h. jedes Programm könnte es auf gut Glück mal versuchen.

> Auch Gruppen können Passworte haben. Allerdings kenne ich kein
> Tool, mit dem man das ähnlich leicht setzen könnte wie mit
> passwd(1). Man muss das verschlüsselte Passwort selbst in
> gshadow(5) eintragen, oder groupmod -p benutzen. Hilfsweise
> könnte man einen Dummy-User anlegen, ein Passwort setzen, und
> dann von shadow(5) nach gshadow(5) kopieren.

gpasswd (1)

--
A. Erhardt

Am 22.04.24 um 22:53 schrieb Arthur Erhardt:

>> Auch Gruppen können Passworte haben. Allerdings kenne ich kein
>> Tool, mit dem man das ähnlich leicht setzen könnte wie mit
>> passwd(1). Man muss das verschlüsselte Passwort selbst in
>> gshadow(5) eintragen, oder groupmod -p benutzen. Hilfsweise
>> könnte man einen Dummy-User anlegen, ein Passwort setzen, und
>> dann von shadow(5) nach gshadow(5) kopieren.
>
> gpasswd (1)

Der Witz ist, die Manpage habe ich beim Schreiben gelesen. Aber
man sollte tatsächlich den Text lesen, auch wenn es nervt, und
nicht nur die Optionen überfliegen. :-)

"gpasswd called by a group administrator with a group name only
prompts for the new password of the group."

MfG

Markus Schaaf <mschaaf@elaboris.de> wrote:
> Am 22.04.24 um 22:53 schrieb Arthur Erhardt:

> >> Auch Gruppen können Passworte haben. Allerdings kenne ich kein
> >> Tool, mit dem man das ähnlich leicht setzen könnte wie mit
> >> passwd(1). Man muss das verschlüsselte Passwort selbst in
> >> gshadow(5) eintragen, oder groupmod -p benutzen. Hilfsweise
> >> könnte man einen Dummy-User anlegen, ein Passwort setzen, und
> >> dann von shadow(5) nach gshadow(5) kopieren.
> >
> > gpasswd (1)

> Der Witz ist, die Manpage habe ich beim Schreiben gelesen. Aber
> man sollte tatsächlich den Text lesen, auch wenn es nervt, und
> nicht nur die Optionen überfliegen. :-)

> "gpasswd called by a group administrator with a group name only
> prompts for the new password of the group."

Ich verstehe Deinen Einwand nicht. Ich hab nur widersprochen, daß man
den Hash (nicht) händisch umkopieren muss. Das trifft bei korrektem
Gebrauch von gpasswd zu. Da ich das selbst nie brauchte hab ichs
eben mal durchgespielt.
Als unprivilegierter User -> permission denied.
Als Admin setzt es klaglos Passworte in Gruppen.

# grep ^cdrom /etc/gshadow
cdrom:*::

# gpasswd cdrom
Changing the password for group cdrom
New Password:
Re-enter new password:

# grep ^cdrom /etc/gshadow
cdrom:$6$S...::

--
A. Erhardt

Am 23.04.24 um 09:56 schrieb Arthur Erhardt:
> Markus Schaaf <mschaaf@elaboris.de> wrote:
>> Am 22.04.24 um 22:53 schrieb Arthur Erhardt:
>
>>>> Auch Gruppen können Passworte haben. Allerdings kenne ich kein
>>>> Tool, mit dem man das ähnlich leicht setzen könnte wie mit
>>>> passwd(1). Man muss das verschlüsselte Passwort selbst in
>>>> gshadow(5) eintragen, oder groupmod -p benutzen. Hilfsweise
>>>> könnte man einen Dummy-User anlegen, ein Passwort setzen, und
>>>> dann von shadow(5) nach gshadow(5) kopieren.
>>>
>>> gpasswd (1)
>
>> Der Witz ist, die Manpage habe ich beim Schreiben gelesen. Aber
>> man sollte tatsächlich den Text lesen, auch wenn es nervt, und
>> nicht nur die Optionen überfliegen. :-)
>
>> "gpasswd called by a group administrator with a group name only
>> prompts for the new password of the group."
>
> Ich verstehe Deinen Einwand nicht.

Du glaubst, ich wollte Dich kritisieren. Dabei habe ich nur über
mich selbst gelacht. Entspann Dich mal. :-)

MfG