Ich betreue große Desktop-Umgebungen mit sehr heterogenen Nutzerkreisen. Für embedded-Entwickler muss ich immer wieder sudo-Regeln bauen, die deren Anforderungen, auch in Bezug auf proprietäre 3rd party Software und Dinge auf der Werkbank so abbilden, dass sie nicht genervt sind, aber gleichzeitig in den security Regeln des Konzerns bleiben. Da kommt dann sowas bei rum wie “darf folgende executable als folgender User starten und nach erstmaliger Authentifizierung bleibt die Berechtigung kennwortlos erhalten bis das Token vom USB-Port gezogen wird oder es nach 19:00 abends ist. Und wir schleppen folgende Teile des userenvs mit in die sudo-Session außer wenn Bedingung X”.
Da findest du dann auf einmal polkit intuitiv und wünschenswert.
Ich sehe definitiv das Problem, aber man sollte nicht das ganze Ding abreißen, das für Millionen anderer User kein Problem darstellt, um Spezialfälle zu lösen. Da wäre es wirklich zumindest angebracht gewesen, darüber nachzudenken, wie man sudo hinsichtlich dieser features erweitert. Ich bin jetzt nicht der polkit-Experte, aber soweit ich das verstehe, müsste man doch im wesentlichen eine rootless sudo-Version bauen, die kein SUID flag hat und polkit nutzt, so wie run0 das auch macht.
Ich finde es ja in der Sache nicht verkehrt, aber immer dieses neu machen nervt. Mit einem kompatiblen replacement hätte man beide Seiten zufriedenstellen können, indem man weiterhin /etc/sudoers als fallback anbietet. podman hat es vorgemacht.
Ach und eins noch: man sollte nicht vergessen, was für eine zentrale Rolle sudo in der Kernkonfiguration der meisten Systeme einnimmt. In gewisser Hinsicht hat es root als user abgelöst, was bedeutet, dass bei einem run0 eine deutlich höhere Komplexität und damit Wartungsproblematik als bei einem verhältnismäßig rudimentären sudo gegeben ist. Das halte ich für kein irrelevantes Argument.
Es gibt ja für alles andere auch generators in systemd, fstab, sysvinit, warum nicht für legacy sudoers. Damit werden dann alte Konfigurationen direkt funktionsfähig.
Ich kann nur empfehlen, ab und an mal die Doku rund um systemd zu durchstöbern. Den Blick auf das gesamte Ökosystem zu haben nimmt viel Frust raus.
Ich glaube, der Frust rührt nicht daher, dass systemd per se schlecht oder falsch konzipiert ist, sondern einfach, dass es zu groß und umfangreich ist und sich in viele Bereiche drängt, an die man sich einfach anderwärtig gewöhnt hat.
Es verstößt eben massiv gegen “ein Werkzeug für eine Aufgabe”.
Was in den seltensten Fällen bei der Verwendung von sudo erforderlich sein dürfte.
Aber ich bin neugierig, kannst du so ein Szenario nennen, wo man an die Grenzen stößt?
Ich betreue große Desktop-Umgebungen mit sehr heterogenen Nutzerkreisen. Für embedded-Entwickler muss ich immer wieder sudo-Regeln bauen, die deren Anforderungen, auch in Bezug auf proprietäre 3rd party Software und Dinge auf der Werkbank so abbilden, dass sie nicht genervt sind, aber gleichzeitig in den security Regeln des Konzerns bleiben. Da kommt dann sowas bei rum wie “darf folgende executable als folgender User starten und nach erstmaliger Authentifizierung bleibt die Berechtigung kennwortlos erhalten bis das Token vom USB-Port gezogen wird oder es nach 19:00 abends ist. Und wir schleppen folgende Teile des userenvs mit in die sudo-Session außer wenn Bedingung X”.
Da findest du dann auf einmal polkit intuitiv und wünschenswert.
@the_third
“Es funktioniert, so lange der Schlüssel steckt, bis zum Feierabend”.
@aaaaaaaaargh @LordCaramac
Hey, nicht mein Regelwerk. Konzern-IT gewöhnt einem vieles ab, vor allem das Mitdenken.
Ich sehe definitiv das Problem, aber man sollte nicht das ganze Ding abreißen, das für Millionen anderer User kein Problem darstellt, um Spezialfälle zu lösen. Da wäre es wirklich zumindest angebracht gewesen, darüber nachzudenken, wie man sudo hinsichtlich dieser features erweitert. Ich bin jetzt nicht der polkit-Experte, aber soweit ich das verstehe, müsste man doch im wesentlichen eine rootless sudo-Version bauen, die kein SUID flag hat und polkit nutzt, so wie run0 das auch macht.
Ich finde es ja in der Sache nicht verkehrt, aber immer dieses neu machen nervt. Mit einem kompatiblen replacement hätte man beide Seiten zufriedenstellen können, indem man weiterhin /etc/sudoers als fallback anbietet. podman hat es vorgemacht.
Ach und eins noch: man sollte nicht vergessen, was für eine zentrale Rolle sudo in der Kernkonfiguration der meisten Systeme einnimmt. In gewisser Hinsicht hat es root als user abgelöst, was bedeutet, dass bei einem run0 eine deutlich höhere Komplexität und damit Wartungsproblematik als bei einem verhältnismäßig rudimentären sudo gegeben ist. Das halte ich für kein irrelevantes Argument.
Es gibt ja für alles andere auch generators in systemd, fstab, sysvinit, warum nicht für legacy sudoers. Damit werden dann alte Konfigurationen direkt funktionsfähig.
Ich kann nur empfehlen, ab und an mal die Doku rund um systemd zu durchstöbern. Den Blick auf das gesamte Ökosystem zu haben nimmt viel Frust raus.
Ich glaube, der Frust rührt nicht daher, dass systemd per se schlecht oder falsch konzipiert ist, sondern einfach, dass es zu groß und umfangreich ist und sich in viele Bereiche drängt, an die man sich einfach anderwärtig gewöhnt hat.
Es verstößt eben massiv gegen “ein Werkzeug für eine Aufgabe”.