Univention Bugzilla – Bug 23173
Problem mit udm cli shares/share (directorymode)
Last modified: 2018-04-13 13:29:21 CEST
Hallo zusammen Ich muss auf einigen Freigaben das "set group ID" Bit setzen und dabei ist mir folgendes aufgefallen. *Hier der normale Zustand [code] udm shares/share modify \ --dn="cn=schule,cn=shares,ou=test,dc=schule,dc=site" \ --set directorymode="0775" [/code] [code] root@ucs-01:/home/groups# ll /home/groups/ | grep schule drwxrwxr-x 10 Administrator Domain Users schule 4096 2011-08-03 04:44 schule [/code] *Das chmod 2775 mit dem udm Befehl abgesetzt: [code] udm shares/share modify \ --dn="cn=schule,cn=shares,ou=test,dc=schule,dc=site" \ --set directorymode="2775" [/code] [code] root@ucs-01:/home/groups# ll /home/groups/ | grep schule d-ws-w-rwt 10 Administrator Domain Users schule 4096 2011-08-03 04:44 schule [/code] *korrekter Vorgang wenn man es von Hand durchführt: [code] root@ucs-01:/home/groups# chmod 2775 schule/ root@ucs-01:/home/groups# ll /home/groups/ | grep schule drwxrwsr-x 10 Administrator Domain Users schule 4096 2011-08-03 04:44 schule [/code] Das ganze würde mich nicht stöhren, wenn man das chmod 2775 von Hand durchführen müsste aber leider haben wir hier ein Problem. Wenn man später eine Anpassung über udm shares/share oder dem WebUDM an dieser Freigabe vornimmt, dann wird von Univention ein chmod (directorymode gemäss LDAP) ausgeführt und mein "set group ID" Bit ist wieder weg! Wie kann ich dies verhindern, oder wie kann ich dieses Problem lösen? http://forum.univention.de/viewtopic.php?f=48&t=1542 mfg,roland
Der Wert wird derzeit direkt an os.chmod übergeben ( "os.chmod(directory, int(mode, 0))" ). os.chmod würde für diesen Fall aber einen fünfstelligen Oktalwert erwarten ( "os.chmod(directory, int('02775',0))" ).
Hallo zusammen Leider mussten wir zu diesem Problem feststellen, dass die Lösung zwar funktioniert aber nicht brauchbar ist. Wenn man diesen Befehl ausführt wird das GID-Bit korrekt gesetzt und alles schein gut zu sein. [code] udm shares/share modify \ --dn="cn=schule,cn=shares,ou=test,dc=schule,dc=site" \ --set directorymode="02775" [/code] Wenn man zu einem späteren Zeitpunkt über das WebUDM dieses Share bearbeitet und irgend eine Anpassung vornimmt, egal was, wird das "directorymode" wieder verändert auf den Wert welchen im WebUDM zusehen ist. Also kann man UID-Bit, GID-Bit und STICKY-Bit nicht verwenden im "directorymode" bei einem Share/Freigabe. mfg, roland
Noch ein paar Anmerkungen dazu. Wir konnten dieses Verhalten auf zwei UCS System reproduzieren überall wird UCS 2.4-3-6 eingesetzt. Man kann die Share Konfiguration mit udm shares/share modify bearbeiten und alles funktioniert korrekt. Die Directory-Mask wird mit dem GID-Bit versehen. Wenn aber, wie vorher beschrieben eine Änderung mittels WebUDM an diesem Share passiert, wird die Directory-Mask wieder auf den Wert zurückgesetzt welches im WebUDM zusehen ist. Wir haben zum Beispiel im WebUDM Share unter den Samba Optionen valid-user angepasst und danach war das GUID-Bit in der Directory-Mask verschwunden. Hier handelt es sich definitv um einen Bug die Einstellungen für das Share wird mit den Werten aus dem WebUDM überschrieben. mfg, roland
Das gewünschte Verhalten wird erreicht, wenn der UDM per UCR angewiesen wird, den directorymode-Wert als String zu interpertieren: ucr set directory/manager/web/modules/shares/share/properties/directorymode/syntax=string Nach einer Neuanmeldung an der UDM-Web-Oberfläche steht dann statt den Checkboxen ein Eingabefeld für den Verzeichnismodus zur Verfügung. Die Eingabe von "02775" ermöglicht die dauerhafte Vergabe der gewünschten Dateirechte. Auch die per UDM-CLI vorgenommenen Änderungen bleiben erhalten. Der Workaround sollte nur angewendet werden, wenn man sich darüber im Klaren ist, was man tut. Es findet keine Überprüfung des übergebenen Wertes statt. Die Verwendung erfolgt auf eigene Gefahr.
Hier sollte die Syntax korrigiert werden. Ausserdem sollte geprüft werden, ob man noch ein DropDown für die weiteren Rechte ergänzt
*** Bug 15086 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 15087 ***