info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
ACL Gefummel
0 views
Skip to first unread message
Tim Ritberg
Jul 10, 2021, 5:10:20 AM7/10/21
to
Hallo!
Für /srv/http brauche ich einige ACLs für bestimmte User und Gruppen.
Zugriff über Samba, das klappt aber schon.
1. User: Apache (www-data)
2. User: ein Dateien-Erzeuger
3. Gruppe: ein paar privilegierte User
4. Gruppe: beinhaltet 2 und 3 (Domain Users)
Die Regeln sollen so gestaltet sein, dass jeder beliebiger User (2.) aus
4. in /srv/http Ordner anlegen kann, aber der sonst niemand aus 4.
Zugriff haben darf, es sei denn er ist in 3.
Meine Versuche sind immer gescheitert, es liegt wohl an der 4. Gruppe.
Tim
Für /srv/http brauche ich einige ACLs für bestimmte User und Gruppen.
Zugriff über Samba, das klappt aber schon.
1. User: Apache (www-data)
2. User: ein Dateien-Erzeuger
3. Gruppe: ein paar privilegierte User
4. Gruppe: beinhaltet 2 und 3 (Domain Users)
Die Regeln sollen so gestaltet sein, dass jeder beliebiger User (2.) aus
4. in /srv/http Ordner anlegen kann, aber der sonst niemand aus 4.
Zugriff haben darf, es sei denn er ist in 3.
Meine Versuche sind immer gescheitert, es liegt wohl an der 4. Gruppe.
Tim
Helmut Waitzmann
Jul 12, 2021, 3:19:36 PM7/12/21
to
Tim Ritberg <t...@server.invalid>:
(Möglicherweise habe ich die Beschreibung nicht vollständig
verstanden; mein Grammatik‐Parser merkt an: Zwei Subjekte im Satz
wurden erkannt. Habe das erste entfernt.)
setfacl -m 'group:4. Gruppe:rwx' -- /srv/http &&
setfacl -d -m 'group:3. Gruppe:rwx' -- /srv/http &&
chmod -- +t /srv/http &&
Das funktioniert nur kooperativ: Jeder Benutzer aus der 4. Gruppe
kann die Zugriffsrechte auf sein erzeugtes Verzeichnis als
Eigentümer natürlich nachträglich ändern, beispielsweise den Zugriff
für Mitglieder der 3. Gruppe verbieten. Will man unkooperatives
Verhalten ausschließen, müssen die von den Benutzern der 4. Gruppe
angelegten Verzeichnisse ihren Eigentümern weggenommen werden. Das
lässt sich mit ACLs alleine nicht ausdrücken.
Man könnte aber mit einem Dienstangebot, das unter der
Benutzerkennung D läuft, arbeiten: Ein Benutzer B1 erzeugt ein
Verzeichnis nicht selbst, sondern bittet den Dienst, das für ihn zu
tun. Der Dienst erzeugt das Verzeichnis unter seiner eigenen
Kennung D, fügt ihm aber per ACLs und per Default‐ACLs Zugriff auf
den Benutzer B1 und auf die 3. Gruppe hinzu.
Der Dienst könnte mit Hilfe von «sudo» implementiert werden: Allen
Benutzern aus der 4. Gruppe muss dann erlaubt werden, mittels «sudo»
unter der Benutzerkennung D das Dienstprogramm (ohne
Passwortabfrage) zu starten, das als Parameter einen
Verzeichnisnamen erhält und das Verzeichnis mit den entsprechenden
Eigenschaften (wie oben beschrieben) anlegt.
Du hast noch nichts dazu geschrieben, was Benutzer mit auf diese
Weise angelegten Verzeichnissen anstellen dürfen sollen. Da wird
sich dann vermutlich dasselbe Problem wieder stellen – nur eine
Ebene tiefer im Dateibaum.
verstanden; mein Grammatik‐Parser merkt an: Zwei Subjekte im Satz
wurden erkannt. Habe das erste entfernt.)
setfacl -m 'group:4. Gruppe:rwx' -- /srv/http &&
setfacl -d -m 'group:3. Gruppe:rwx' -- /srv/http &&
chmod -- +t /srv/http &&
Das funktioniert nur kooperativ: Jeder Benutzer aus der 4. Gruppe
kann die Zugriffsrechte auf sein erzeugtes Verzeichnis als
Eigentümer natürlich nachträglich ändern, beispielsweise den Zugriff
für Mitglieder der 3. Gruppe verbieten. Will man unkooperatives
Verhalten ausschließen, müssen die von den Benutzern der 4. Gruppe
angelegten Verzeichnisse ihren Eigentümern weggenommen werden. Das
lässt sich mit ACLs alleine nicht ausdrücken.
Man könnte aber mit einem Dienstangebot, das unter der
Benutzerkennung D läuft, arbeiten: Ein Benutzer B1 erzeugt ein
Verzeichnis nicht selbst, sondern bittet den Dienst, das für ihn zu
tun. Der Dienst erzeugt das Verzeichnis unter seiner eigenen
Kennung D, fügt ihm aber per ACLs und per Default‐ACLs Zugriff auf
den Benutzer B1 und auf die 3. Gruppe hinzu.
Der Dienst könnte mit Hilfe von «sudo» implementiert werden: Allen
Benutzern aus der 4. Gruppe muss dann erlaubt werden, mittels «sudo»
unter der Benutzerkennung D das Dienstprogramm (ohne
Passwortabfrage) zu starten, das als Parameter einen
Verzeichnisnamen erhält und das Verzeichnis mit den entsprechenden
Eigenschaften (wie oben beschrieben) anlegt.
Du hast noch nichts dazu geschrieben, was Benutzer mit auf diese
Weise angelegten Verzeichnissen anstellen dürfen sollen. Da wird
sich dann vermutlich dasselbe Problem wieder stellen – nur eine
Ebene tiefer im Dateibaum.
Tim Ritberg
Jul 12, 2021, 4:10:12 PM7/12/21
to
Am 12.07.21 um 21:10 schrieb Helmut Waitzmann:
was auch geplant war.
>
> Man könnte aber mit einem Dienstangebot, das unter der Benutzerkennung D
> läuft, arbeiten: Ein Benutzer B1 erzeugt ein Verzeichnis nicht selbst,
> sondern bittet den Dienst, das für ihn zu tun.
Die Idee hatte ich schon. Es lässt sich aber wohl auch noch anders
lösen, wenn man die Gruppe auf www-data setzt mit Setgid.
Tim
> (Möglicherweise habe ich die Beschreibung nicht vollständig verstanden;
> mein Grammatik‐Parser merkt an: Zwei Subjekte im Satz wurden erkannt.
> Habe das erste entfernt.)
>
> setfacl -m 'group:4. Gruppe:rwx' -- /srv/http &&
> setfacl -d -m 'group:3. Gruppe:rwx' -- /srv/http &&
> chmod -- +t /srv/http &&
>
> Das funktioniert nur kooperativ: Jeder Benutzer aus der 4. Gruppe kann
> die Zugriffsrechte auf sein erzeugtes Verzeichnis als Eigentümer
> natürlich nachträglich ändern, beispielsweise den Zugriff für Mitglieder
> der 3. Gruppe verbieten. Will man unkooperatives Verhalten
> ausschließen, müssen die von den Benutzern der 4. Gruppe angelegten
> Verzeichnisse ihren Eigentümern weggenommen werden. Das lässt sich mit
> ACLs alleine nicht ausdrücken.
Das ist nicht schlimm, so kann er weiteren Usern den Zugriff erlauben,
> mein Grammatik‐Parser merkt an: Zwei Subjekte im Satz wurden erkannt.
> Habe das erste entfernt.)
>
> setfacl -m 'group:4. Gruppe:rwx' -- /srv/http &&
> setfacl -d -m 'group:3. Gruppe:rwx' -- /srv/http &&
> chmod -- +t /srv/http &&
>
> Das funktioniert nur kooperativ: Jeder Benutzer aus der 4. Gruppe kann
> die Zugriffsrechte auf sein erzeugtes Verzeichnis als Eigentümer
> natürlich nachträglich ändern, beispielsweise den Zugriff für Mitglieder
> der 3. Gruppe verbieten. Will man unkooperatives Verhalten
> ausschließen, müssen die von den Benutzern der 4. Gruppe angelegten
> Verzeichnisse ihren Eigentümern weggenommen werden. Das lässt sich mit
> ACLs alleine nicht ausdrücken.
was auch geplant war.
>
> Man könnte aber mit einem Dienstangebot, das unter der Benutzerkennung D
> läuft, arbeiten: Ein Benutzer B1 erzeugt ein Verzeichnis nicht selbst,
> sondern bittet den Dienst, das für ihn zu tun.
lösen, wenn man die Gruppe auf www-data setzt mit Setgid.
>
> Du hast noch nichts dazu geschrieben, was Benutzer mit auf diese Weise
> angelegten Verzeichnissen anstellen dürfen sollen. Da wird sich dann
> vermutlich dasselbe Problem wieder stellen – nur eine Ebene tiefer im
> Dateibaum.
Webseiten ablegen.
> Du hast noch nichts dazu geschrieben, was Benutzer mit auf diese Weise
> angelegten Verzeichnissen anstellen dürfen sollen. Da wird sich dann
> vermutlich dasselbe Problem wieder stellen – nur eine Ebene tiefer im
> Dateibaum.
Tim
Helmut Waitzmann
Jul 13, 2021, 4:53:44 PM7/13/21
to
Tim Ritberg <t...@server.invalid>:
ausgedrückt hatte: Unkooperatives Verhalten kann auch bedeuten,
dass ein Benutzer der 4. Gruppe den Benutzern der 3. Gruppe den
Zugriff verbietet. Solange die von einem Benutzer angelegten Dateien oder
Verzeichnisse ihm weiterhin gehören, kann er alle Zugriffsrechte –
auch die, die von Default‐ACLs stammen – nachträglich ändern.
>> Man könnte aber mit einem Dienstangebot, das unter der
>> Benutzerkennung D läuft, arbeiten: Ein Benutzer B1 erzeugt ein
>> Verzeichnis nicht selbst, sondern bittet den Dienst, das für ihn
>> zu tun.
>Die Idee hatte ich schon. Es lässt sich aber wohl auch noch anders
>lösen, wenn man die Gruppe auf www-data setzt mit Setgid.
Verstehe ich dich richtig? Das Verzeichnis «/srv/http» soll die
Gruppe «www-data» mit Set‐GId‐Bit erhalten? Das wirkt so ähnlich
wie Default‐ACLs und verhindert ebenso wenig unkooperatives
Verhalten wie Default‐ACLs. Im Gegensatz zu Default‐ACLs entmachtet
es zusätzlich nicht das file creation mask. Was ACLs mit dem file
creation mask anstellen, steht im Abschnitt «OBJECT CREATION AND
DEFAULT ACLs» des Handbuchs «acl(5)».
Wenn unkooperatives Verhalten kein Problem ist (etwa, weil alle
kooperieren), genügen (Default‐) ACLs, um den Teilnehmern
kooperatives Verhalten zu erleichtern.
>> Du hast noch nichts dazu geschrieben, was Benutzer mit auf diese
>> Weise angelegten Verzeichnissen anstellen dürfen sollen. Da wird
>> sich dann vermutlich dasselbe Problem wieder stellen – nur eine
>> Ebene tiefer im Dateibaum.
>Webseiten ablegen.
>
Wenn das in der Sprache des Dateisystems bedeutet, Dateien zu
erzeugen, ist das mit ACLs genau so machbar wie bei den
Verzeichnissen.
>Am 12.07.21 um 21:10 schrieb Helmut Waitzmann:
>> setfacl -m 'group:4. Gruppe:rwx' -- /srv/http &&
>> setfacl -d -m 'group:3. Gruppe:rwx' -- /srv/http &&
>> chmod -- +t /srv/http &&
>>
>> Das funktioniert nur kooperativ: Jeder Benutzer aus der
>> 4. Gruppe kann die Zugriffsrechte auf sein erzeugtes Verzeichnis
>> als Eigentümer natürlich nachträglich ändern, beispielsweise den
>> Zugriff für Mitglieder der 3. Gruppe verbieten. Will man
>> unkooperatives Verhalten ausschließen, müssen die von den
>> Benutzern der 4. Gruppe angelegten Verzeichnisse ihren
>> Eigentümern weggenommen werden. Das lässt sich mit ACLs alleine
>> nicht ausdrücken.
>Das ist nicht schlimm, so kann er weiteren Usern den Zugriff
>erlauben, was auch geplant war.
Ich bin mir jetzt nicht sicher, ob ich mich unmissverständlich
>> setfacl -d -m 'group:3. Gruppe:rwx' -- /srv/http &&
>> chmod -- +t /srv/http &&
>>
>> Das funktioniert nur kooperativ: Jeder Benutzer aus der
>> 4. Gruppe kann die Zugriffsrechte auf sein erzeugtes Verzeichnis
>> als Eigentümer natürlich nachträglich ändern, beispielsweise den
>> Zugriff für Mitglieder der 3. Gruppe verbieten. Will man
>> unkooperatives Verhalten ausschließen, müssen die von den
>> Benutzern der 4. Gruppe angelegten Verzeichnisse ihren
>> Eigentümern weggenommen werden. Das lässt sich mit ACLs alleine
>> nicht ausdrücken.
>Das ist nicht schlimm, so kann er weiteren Usern den Zugriff
>erlauben, was auch geplant war.
ausgedrückt hatte: Unkooperatives Verhalten kann auch bedeuten,
dass ein Benutzer der 4. Gruppe den Benutzern der 3. Gruppe den
Zugriff verbietet. Solange die von einem Benutzer angelegten Dateien oder
Verzeichnisse ihm weiterhin gehören, kann er alle Zugriffsrechte –
auch die, die von Default‐ACLs stammen – nachträglich ändern.
>> Man könnte aber mit einem Dienstangebot, das unter der
>> Benutzerkennung D läuft, arbeiten: Ein Benutzer B1 erzeugt ein
>> Verzeichnis nicht selbst, sondern bittet den Dienst, das für ihn
>> zu tun.
>Die Idee hatte ich schon. Es lässt sich aber wohl auch noch anders
>lösen, wenn man die Gruppe auf www-data setzt mit Setgid.
Gruppe «www-data» mit Set‐GId‐Bit erhalten? Das wirkt so ähnlich
wie Default‐ACLs und verhindert ebenso wenig unkooperatives
Verhalten wie Default‐ACLs. Im Gegensatz zu Default‐ACLs entmachtet
es zusätzlich nicht das file creation mask. Was ACLs mit dem file
creation mask anstellen, steht im Abschnitt «OBJECT CREATION AND
DEFAULT ACLs» des Handbuchs «acl(5)».
Wenn unkooperatives Verhalten kein Problem ist (etwa, weil alle
kooperieren), genügen (Default‐) ACLs, um den Teilnehmern
kooperatives Verhalten zu erleichtern.
>> Du hast noch nichts dazu geschrieben, was Benutzer mit auf diese
>> Weise angelegten Verzeichnissen anstellen dürfen sollen. Da wird
>> sich dann vermutlich dasselbe Problem wieder stellen – nur eine
>> Ebene tiefer im Dateibaum.
>Webseiten ablegen.
>
erzeugen, ist das mit ACLs genau so machbar wie bei den
Verzeichnissen.
Tim Ritberg
Jul 14, 2021, 5:43:30 AM7/14/21
to
Am 13.07.21 um 22:04 schrieb Helmut Waitzmann:
>> Das ist nicht schlimm, so kann er weiteren Usern den Zugriff erlauben,
>> was auch geplant war.
>
> Ich bin mir jetzt nicht sicher, ob ich mich unmissverständlich
> ausgedrückt hatte: Unkooperatives Verhalten kann auch bedeuten, dass
> ein Benutzer der 4. Gruppe den Benutzern der 3. Gruppe den Zugriff
> verbietet. Solange die von einem Benutzer angelegten Dateien oder
> Verzeichnisse ihm weiterhin gehören, kann er alle Zugriffsrechte – auch
> die, die von Default‐ACLs stammen – nachträglich ändern.
Ähm ja...über Shell könnte er es wohl, aber nicht über Samba, wie es
aussieht.
>
> Verstehe ich dich richtig? Das Verzeichnis «/srv/http» soll die Gruppe
> «www-data» mit Set‐GId‐Bit erhalten? Das wirkt so ähnlich wie
> Default‐ACLs und verhindert ebenso wenig unkooperatives Verhalten wie
> Default‐ACLs. Im Gegensatz zu Default‐ACLs entmachtet es zusätzlich
> nicht das file creation mask. Was ACLs mit dem file creation mask
> anstellen, steht im Abschnitt «OBJECT CREATION AND DEFAULT ACLs» des
> Handbuchs «acl(5)».
Ich habe es bisher nicht anders geschafft, die Gruppe "Domain Users"
anders auszusperren.
Zusätzlich habe ich noch eine default acl "default:group:Domain
Users:---". Die scheint aber nutzlos, wenn die Gruppe auf Domain Users
steht.
> Wenn unkooperatives Verhalten kein Problem ist (etwa, weil alle
> kooperieren), genügen (Default‐) ACLs, um den Teilnehmern kooperatives
> Verhalten zu erleichtern.
Kooperation aber nur über die Gruppe 3, was so eine Art root light ist.
Ich habe als root keine Lust, hier nachträglich Rechte vergeben zu
müssen, soll jemand aus der Gruppe 3 machen.
>
> Wenn das in der Sprache des Dateisystems bedeutet, Dateien zu erzeugen,
> ist das mit ACLs genau so machbar wie bei den Verzeichnissen.
Joa. Klappt noch nicht so alles.
Vielleicht muss ich doch einen bestimmten Teil von eibem Sudo-Script
erledigen lassen.
Tim
>> Das ist nicht schlimm, so kann er weiteren Usern den Zugriff erlauben,
>> was auch geplant war.
>
> Ich bin mir jetzt nicht sicher, ob ich mich unmissverständlich
> ausgedrückt hatte: Unkooperatives Verhalten kann auch bedeuten, dass
> ein Benutzer der 4. Gruppe den Benutzern der 3. Gruppe den Zugriff
> verbietet. Solange die von einem Benutzer angelegten Dateien oder
> Verzeichnisse ihm weiterhin gehören, kann er alle Zugriffsrechte – auch
> die, die von Default‐ACLs stammen – nachträglich ändern.
aussieht.
>
> Verstehe ich dich richtig? Das Verzeichnis «/srv/http» soll die Gruppe
> «www-data» mit Set‐GId‐Bit erhalten? Das wirkt so ähnlich wie
> Default‐ACLs und verhindert ebenso wenig unkooperatives Verhalten wie
> Default‐ACLs. Im Gegensatz zu Default‐ACLs entmachtet es zusätzlich
> nicht das file creation mask. Was ACLs mit dem file creation mask
> anstellen, steht im Abschnitt «OBJECT CREATION AND DEFAULT ACLs» des
> Handbuchs «acl(5)».
anders auszusperren.
Zusätzlich habe ich noch eine default acl "default:group:Domain
Users:---". Die scheint aber nutzlos, wenn die Gruppe auf Domain Users
steht.
> Wenn unkooperatives Verhalten kein Problem ist (etwa, weil alle
> kooperieren), genügen (Default‐) ACLs, um den Teilnehmern kooperatives
> Verhalten zu erleichtern.
Ich habe als root keine Lust, hier nachträglich Rechte vergeben zu
müssen, soll jemand aus der Gruppe 3 machen.
>
> Wenn das in der Sprache des Dateisystems bedeutet, Dateien zu erzeugen,
> ist das mit ACLs genau so machbar wie bei den Verzeichnissen.
Vielleicht muss ich doch einen bestimmten Teil von eibem Sudo-Script
erledigen lassen.
Tim
Helmut Waitzmann
Jul 15, 2021, 7:29:00 PM7/15/21
to
Tim Ritberg <t...@server.invalid>:
können.
>> Verstehe ich dich richtig? Das Verzeichnis «/srv/http» soll die
>> Gruppe «www-data» mit Set‐GId‐Bit erhalten? Das wirkt so ähnlich
>> wie Default‐ACLs und verhindert ebenso wenig unkooperatives
>> Verhalten wie Default‐ACLs. Im Gegensatz zu Default‐ACLs entmachtet
>> es zusätzlich nicht das file creation mask. Was ACLs mit dem file
>> creation mask anstellen, steht im Abschnitt «OBJECT CREATION AND
>> DEFAULT ACLs» des Handbuchs «acl(5)».
>Ich habe es bisher nicht anders geschafft, die Gruppe "Domain Users"
>anders auszusperren.
>Zusätzlich habe ich noch eine default acl "default:group:Domain
>Users:---". Die scheint aber nutzlos, wenn die Gruppe auf Domain
>Users steht.
Du müsstest noch «default:group::---» mit angeben.
>> Wenn unkooperatives Verhalten kein Problem ist (etwa, weil alle
>> kooperieren), genügen (Default‐) ACLs, um den Teilnehmern
>> kooperatives Verhalten zu erleichtern.
>Kooperation aber nur über die Gruppe 3, was so eine Art root light
>ist. Ich habe als root keine Lust, hier nachträglich Rechte
>vergeben zu müssen, soll jemand aus der Gruppe 3 machen.
Das wird nicht gehen: Die Zugriffsrechte eines Inodes kann
(traditionell) nur der Eigentümer oder «root» ändern. Solange ein
unkooperativer Benutzer der Gruppe 3 keinen Zugriff gewährt, hilft
es einem Nicht‐«root»‐Prozess nicht, Mitglied der Gruppe 3 zu sein:
Er kann trotzdem die Zugriffsrechte eines fremden Inodes nicht
ändern.
Außerdem: Nachträglich Rechte zu vergeben oder Eigentümerschaft zu
ändern, ist eine gefährliche Angelegenheit. Wenn man da nicht
verhindert, dass jemand mit einem Symlink‐Angriff «root» dazu
verführt, am falschen Inode die Zugriffsrechte oder die
Eigentümerschaft zu ändern, ist das gesamte System in Gefahr,
gekapert zu werden.
>Vielleicht muss ich doch einen bestimmten Teil von eibem
>Sudo-Script erledigen lassen.
Wenn man unkooperatives Verhalten vereiteln will, kommt man nicht
darum herum, auf irgend eine Weise einen sorgfältig beschränkten
Dienst anzubieten, der es von vorneherein verhindert, dass Benutzer
aus der Gruppe 4 Inodes unkooperative Zugriffsrechte verpassen.
>Am 13.07.21 um 22:04 schrieb Helmut Waitzmann:
>>> Das ist nicht schlimm, so kann er weiteren Usern den Zugriff
>>> erlauben, was auch geplant war.
>>
>> Ich bin mir jetzt nicht sicher, ob ich mich unmissverständlich
>> ausgedrückt hatte: Unkooperatives Verhalten kann auch bedeuten,
>> dass ein Benutzer der 4. Gruppe den Benutzern der 3. Gruppe den
>> Zugriff verbietet. Solange die von einem Benutzer angelegten
>> Dateien oder Verzeichnisse ihm weiterhin gehören, kann er alle
>> Zugriffsrechte – auch die, die von Default‐ACLs stammen –
>> nachträglich ändern.
>
>Ähm ja...über Shell könnte er es wohl, aber nicht über Samba, wie
>es aussieht.
Mit Samba kenn' ich mich nicht genug aus, um das beurteilen zu
>>> Das ist nicht schlimm, so kann er weiteren Usern den Zugriff
>>> erlauben, was auch geplant war.
>>
>> Ich bin mir jetzt nicht sicher, ob ich mich unmissverständlich
>> ausgedrückt hatte: Unkooperatives Verhalten kann auch bedeuten,
>> dass ein Benutzer der 4. Gruppe den Benutzern der 3. Gruppe den
>> Zugriff verbietet. Solange die von einem Benutzer angelegten
>> Dateien oder Verzeichnisse ihm weiterhin gehören, kann er alle
>> Zugriffsrechte – auch die, die von Default‐ACLs stammen –
>> nachträglich ändern.
>
>Ähm ja...über Shell könnte er es wohl, aber nicht über Samba, wie
>es aussieht.
können.
>> Verstehe ich dich richtig? Das Verzeichnis «/srv/http» soll die
>> Gruppe «www-data» mit Set‐GId‐Bit erhalten? Das wirkt so ähnlich
>> wie Default‐ACLs und verhindert ebenso wenig unkooperatives
>> Verhalten wie Default‐ACLs. Im Gegensatz zu Default‐ACLs entmachtet
>> es zusätzlich nicht das file creation mask. Was ACLs mit dem file
>> creation mask anstellen, steht im Abschnitt «OBJECT CREATION AND
>> DEFAULT ACLs» des Handbuchs «acl(5)».
>Ich habe es bisher nicht anders geschafft, die Gruppe "Domain Users"
>anders auszusperren.
>Zusätzlich habe ich noch eine default acl "default:group:Domain
>Users:---". Die scheint aber nutzlos, wenn die Gruppe auf Domain
>Users steht.
>> Wenn unkooperatives Verhalten kein Problem ist (etwa, weil alle
>> kooperieren), genügen (Default‐) ACLs, um den Teilnehmern
>> kooperatives Verhalten zu erleichtern.
>Kooperation aber nur über die Gruppe 3, was so eine Art root light
>ist. Ich habe als root keine Lust, hier nachträglich Rechte
>vergeben zu müssen, soll jemand aus der Gruppe 3 machen.
(traditionell) nur der Eigentümer oder «root» ändern. Solange ein
unkooperativer Benutzer der Gruppe 3 keinen Zugriff gewährt, hilft
es einem Nicht‐«root»‐Prozess nicht, Mitglied der Gruppe 3 zu sein:
Er kann trotzdem die Zugriffsrechte eines fremden Inodes nicht
ändern.
Außerdem: Nachträglich Rechte zu vergeben oder Eigentümerschaft zu
ändern, ist eine gefährliche Angelegenheit. Wenn man da nicht
verhindert, dass jemand mit einem Symlink‐Angriff «root» dazu
verführt, am falschen Inode die Zugriffsrechte oder die
Eigentümerschaft zu ändern, ist das gesamte System in Gefahr,
gekapert zu werden.
>Vielleicht muss ich doch einen bestimmten Teil von eibem
>Sudo-Script erledigen lassen.
darum herum, auf irgend eine Weise einen sorgfältig beschränkten
Dienst anzubieten, der es von vorneherein verhindert, dass Benutzer
aus der Gruppe 4 Inodes unkooperative Zugriffsrechte verpassen.
Tim Ritberg
Jul 27, 2021, 4:43:28 AM7/27/21
to
Am 16.07.21 um 01:28 schrieb Helmut Waitzmann:
Weiterhin kann Samba nicht mehr das setgid vererben (Bug?). Das ist
jetzt mein Problem.
Tim
>
> Du müsstest noch «default:group::---» mit angeben.
Scheinbar nicht, Samba verhält sich anders als die Shell.
> Du müsstest noch «default:group::---» mit angeben.
Weiterhin kann Samba nicht mehr das setgid vererben (Bug?). Das ist
jetzt mein Problem.
Tim
Stefan Froehlich
Jul 27, 2021, 8:48:59 AM7/27/21
to
Fileserver innerhalb der Domain - aufgesetzt und weiss nur noch,
dass die Berechtigungen extrem anstrengend waren, weil die
Unix-Berechtigungen von Samba um eigene Logik erweitert werden, um
die Möglichkeiten von Windows vollständig abbilden zu können.
Richtig konfiguriert lässt sich das dann unter Windows graphisch
verwalten (und gar nicht einmal so schlecht).
Schau Dir in der smb.conf und in der zugehörigen man-Page die
Optionen
vfs objects
inherit acls
inherit owner
map acl inherit
store dos attributes
an. Eventuell gibt es noch ein paar mehr in diesem Dunstkreis, über
die ich damals nicht gestolpert bin.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
Ein Traum zum Kuscheln - Stefan: bröckeln, welch kolossales Begehren!
(Sloganizer)
Tim Ritberg
Jul 27, 2021, 9:53:17 AM7/27/21
to
Am 27.07.21 um 14:48 schrieb Stefan Froehlich:
So klappts.
# file: .
# owner: root
# group: nogroup
user::rwx
user:www-data:rwx
group::---
group:Domain\040Users:rwx
mask::rwx
other::---
default:user::rwx
default:user:www-data:rwx
default:group::---
default:group:BesondereGruppe:rwx
default:mask::rwx
default:other::---
Diese besondere Gruppe kann dann mit einem Script über sudo weitere User
hinzufügen.
Tim
>
> Ich habe vor zwei Jahren ein paar Samba-Server - sowohl DC, als auch
> Fileserver innerhalb der Domain - aufgesetzt und weiss nur noch,
> dass die Berechtigungen extrem anstrengend waren, weil die
> Unix-Berechtigungen von Samba um eigene Logik erweitert werden, um
> die Möglichkeiten von Windows vollständig abbilden zu können.
Ich hab es jetzt hinbekommen. Da waren noch default acl falsch.
> Ich habe vor zwei Jahren ein paar Samba-Server - sowohl DC, als auch
> Fileserver innerhalb der Domain - aufgesetzt und weiss nur noch,
> dass die Berechtigungen extrem anstrengend waren, weil die
> Unix-Berechtigungen von Samba um eigene Logik erweitert werden, um
> die Möglichkeiten von Windows vollständig abbilden zu können.
So klappts.
# file: .
# owner: root
# group: nogroup
user::rwx
user:www-data:rwx
group::---
group:Domain\040Users:rwx
mask::rwx
other::---
default:user::rwx
default:user:www-data:rwx
default:group::---
default:group:BesondereGruppe:rwx
default:mask::rwx
default:other::---
Diese besondere Gruppe kann dann mit einem Script über sudo weitere User
hinzufügen.
Tim
Bastian Blank
Aug 10, 2021, 3:42:16 PM8/10/21
to
Tim Ritberg wrote:
> Für /srv/http brauche ich einige ACLs für bestimmte User und Gruppen.
> Zugriff über Samba, das klappt aber schon.
> Für /srv/http brauche ich einige ACLs für bestimmte User und Gruppen.
> Zugriff über Samba, das klappt aber schon.
> Die Regeln sollen so gestaltet sein, dass jeder beliebiger User (2.) aus
> 4. in /srv/http Ordner anlegen kann, aber der sonst niemand aus 4.
> Zugriff haben darf, es sei denn er ist in 3.
Ehrliche Antwort? Such dir eine spezialisierte und gemaintainte
> 4. in /srv/http Ordner anlegen kann, aber der sonst niemand aus 4.
> Zugriff haben darf, es sei denn er ist in 3.
Anwendung für deinen Anwendungsfall. Sowas wie GitLab Pages wenn es dir
um Webseiten geht.[1] Oder evtl NextCloud wenn es um Datenaustausch
geht.[2]
Bastian
[1]: https://docs.gitlab.com/ee/user/project/pages/
[2]: https://nextcloud.com/file-drop/
Tim Ritberg
Aug 10, 2021, 3:53:24 PM8/10/21
to
Am 10.08.21 um 21:42 schrieb Bastian Blank:
Tim
> Tim Ritberg wrote:
>> Für /srv/http brauche ich einige ACLs für bestimmte User und Gruppen.
>> Zugriff über Samba, das klappt aber schon.
>> Die Regeln sollen so gestaltet sein, dass jeder beliebiger User (2.) aus
>> 4. in /srv/http Ordner anlegen kann, aber der sonst niemand aus 4.
>> Zugriff haben darf, es sei denn er ist in 3.
>
> Ehrliche Antwort? Such dir eine spezialisierte und gemaintainte
> Anwendung für deinen Anwendungsfall. Sowas wie GitLab Pages wenn es dir
> um Webseiten geht.[1] Oder evtl NextCloud wenn es um Datenaustausch
> geht.[2]
>
> Bastian
Ehrliche Antwort? nö!
>> Für /srv/http brauche ich einige ACLs für bestimmte User und Gruppen.
>> Zugriff über Samba, das klappt aber schon.
>> Die Regeln sollen so gestaltet sein, dass jeder beliebiger User (2.) aus
>> 4. in /srv/http Ordner anlegen kann, aber der sonst niemand aus 4.
>> Zugriff haben darf, es sei denn er ist in 3.
>
> Ehrliche Antwort? Such dir eine spezialisierte und gemaintainte
> Anwendung für deinen Anwendungsfall. Sowas wie GitLab Pages wenn es dir
> um Webseiten geht.[1] Oder evtl NextCloud wenn es um Datenaustausch
> geht.[2]
>
> Bastian
Tim
0 new messages