31.05.2016

4127

Windows ACL "Löschen verweigern" greift nicht - Datei lässt sich immer löschen

Hallo (hoffentlich) Wissende,

ich habe ein Problem bezüglich der Rechtevergabe bzw. dessen Entzug.
Eine Software schreibt seine Lizenzprüfung (license.zip) in sein Programmverzeichnis, entpackt sie und löscht sie anschliessend wieder.
Ich möchte dem Nutzer gerne verweigern in dem Programmverzeichnis zu schreiben, muss allerdings eben jene License.zip erlauben.

Meine Idee war daher die Datei sowie die beiden entpackten Dateien als schreibbar zu deklarieren (den Rest halt nicht). Soweit so gut.

Leider löscht das Programm die Datei immer wieder - daher die Idee dem Nutzer das löschen der Datei zu verweigern (Änderung aber zu erlauben), so dass die eingestellten Rechte erhalten bleiben.

Kurz also drei schreibbare Dateien in einem nicht schreibbaren Verzeichnis welche nicht gelöscht werden können.

Leider greift das "Löschen verweigern" nicht. Ich kann einen Rechteeintrag setzen für die Benutzergruppe bei der Löschen auf Verweigert steht, allerdings kann der Nutzer die Datei sofort löschen Sobald die Nutzergruppe auch ändern hat. Normalerweise sollte ein "Verweigern" Eintrag doch immer vorrangig sein?

Systeminfo: Windows 2008R2 - Dateifreigabe mit den vollen Rechten für fragliche Benutzergruppe und Admins
Client: Windows 7 / Windows 10 - spielt keine Rolle

Rechte des übergeordneten Ordners:

System (Voll - geerbt)
Benutzergruppe (lesen, ausführen - geerbt)
Administratoren (Voll - geerbt)
Besitzer: Administratoren

Rechte der Datei:

System und Admins - Voll
Benutzer (lesen, ausführen - geerbt) (ändern - einzeln) (löschen verweigert - einzeln)
Besitzer: Administratoren

Bei Prüfung der effektiven Rechte wird angezeigt das dem Nutzer das löschen verweigert wird - Löschen kann er die Datei trotzdem.

Was mache ich falsch?

PS: Testweise habe ich auch das ganze für Admins probiert - selbst wenn ich Admins und System "Löschen verweigere" kann ich die Datei problemlos löschen. Beiden habe ich vorher den Vollzugriff (nur ändern) auf Überordner und Datei entzogen

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 305793

Url: https://administrator.de/forum/windows-acl-loeschen-verweigern-greift-nicht-datei-laesst-sich-immer-loeschen-305793.html

Ausgedruckt am: 22.12.2024 um 22:12 Uhr

28 Kommentare

Neuester Kommentar

Moin,

es ist sehr warm ... wenn ich mich nicht ganz täusche, ist das, was du vor hast, schlicht nicht abbildbar. Ändern = Löschen.

Gruß Krämer

PS: Schon wieder so ne kranke Softwareschmiede, die die letzen 20 Jahre verschlafen hat...

The Delete permission allows or denies the user from deleting the file or folder. If you do not have a Delete permission on a file or folder, you can delete the file or folder if you are granted Delete Subfolders and Files permissions on the parent folder

https://technet.microsoft.com/en-us/library/cc732880(v=ws.11).aspx

Gruß skybird

Dieses Recht ist wie schon erläutert nicht vorhanden - auf dem übergeordneten Ordner hat er nur Lese/Ausführ-Rechte.

Und ja, die haben einen Clown gefrühstückt.
Die Software benötigt Admin-Rechte zum starten - weil man seine Registry-keys mit den Benutzereinstellungen in LocalMachine ablegt und nicht in LocalUser... Antwort vom Support war, dass ich dem Nutzer einfach lokale Adminrechte einräumen soll.
Als Nutzerdatenbank kommt eine Datenbank in einer Version zum Einsatz welche bereits seit 20 Jahren nicht mehr gepflegt wird... (nicht übertrieben - Supportende 1996)

Die Software benötigt Admin-Rechte zum starten

Da haben wird den Knackpunkt, die Software läuft mit lokalen Admin-Rechten, und deswegen kann sie das File auch löschen

Die SW soll ja löschen können - die Benutzer aber nicht...

Leider löscht das Programm die Datei immer wieder - daher die Idee dem Nutzer das löschen der Datei zu verweigern (Änderung aber zu erlauben), so dass die eingestellten Rechte erhalten bleiben.

Das bringt absolut garnichts, wenn das Programm im Kontext eines Admins läuft, da müsstest du schon den Zugriff für die Admins entziehen.

Wenn ich das richtig durchschaue versucht er ja gerade die Software ohne Adminrechte laufen zu lassen - sprich er gibt soviel frei wie nur unbedingt nötig.

Hi,
wenn es nur das Schreiben in der Registry und in diesem einen Programm-Ordner sind, dann kann man das durch gezielte Rechtevergabe auf die Schlüssel im HKLM und dem Programm-Ordner im NTFS regeln. Dafür benötigt der Benutzer keine Adminrechte.

E.

Korrekt erfasst - das war die vorgeschlagene Lösung des Supports - nicht meine.

Das Programm läuft (dank angepasster Registry) nun ohne Adminrechte - kann aber keine Katalog-Updates laden ohne die Lizenzdatei.
Diese läd es entsprechend den Berechtigungen des Nutzers. Entsprechend bräuchte er auch hier Schreib- UND Ausführrechte auf das Programmverzeichnis.

Diese Kombination versuche ich möglichst zu vermeiden - entweder Schreiben oder Ausführen. Da die erwähnten aber die einzigen sind die abseits der Programmupdates wirklich Schreibrechte brauchen suche wie ich schon beschrieben eine Lösung nur für diese drei Dateien Schreibrechte einzuräumen.

Da das Programm aber wie gesagt die zip jedesmal wieder löscht kann ich bisher die Rechte nicht persistent vergeben - sprich sobald die zip weg ist kann sie erstmal nicht neu geschrieben werden. Daher der Versuch genau diese Löschen zu unterbinden.

Und ich schätze, das mit dem "Löschen verweigern" hast Du nicht wirklich im Benutzerkontext getestet. (ein Nicht-Admin)
Wenn ein Benutzer für einen Ordner nur die effektiven Rechte (über den User + über alle seine Gruppen)
- Löschen -- verweigern
- Ordner durchsuchen / Datei ausführen -- erlauben
- Ordner auflisten / Daten lesen -- erlauben
- Attribute lesen -- erlauben
- erweiterte Attribute lesen -- erlauben
- Dateien erstellen / Daten schreiben -- erlauben
- Ordner erstellen / Daten anhängen -- erlauben

dann kan er
- Ordner erstellen
- Dateien erstellen (beachte: Nicht über Explorer-Kontextmenü, aber über Kopieren oder z.B. "Speichern unter" aus einem Programm heraus.)
- Ornder nicht löschen
- Dateien nicht löschen
- Dateien ändern

Habe ich eben nochmal getestet.

Edit:
Es fehlen noch ... (dann gehts auch mit Ändern der Datei)
- Attribute schreiben -- erlauben
- Erweiterte Attribute schreiben -- erlauben

Für die vorhandenen Dateien (EXE, DLL usw.), welche nicht geändert werden dürfen, die beiden letztgenannten Rechte je Datei einzeln verweigern.

Es ist so warm hier...
Das löschen der Dateien wirst du nicht verhindern können - das Programm würde deswegen wahrscheinlich eh meckern.
Schreibe dir doch ein kleines Batch, welches die Dateien beim herunterfahren des Rechners mit 1 Byte Größe erstellt (fsutil) und setze dann die Rechte der Dateien neu.

Er hat das ursprünglich über die File-ACLs versucht nicht über die Ordner ACLs, da ist klar das das so nicht gehen kann, wenn er die Vererbung nicht unterbricht und die Ordner ACLs entsprechend customized.

Im Anhang sind die aktuellen Rechte.
Generell das löschen für das Programmverzeichnis verweigern kann ich (um es zu vererben) nicht, da ansonsten in einem Unterordner abgelegte Updates nicht mehr gelöscht werden würden (anderes Problem...). Dorthin darf der Nutzer schreiben, aber nicht ausführen. Löschen muss er dort können.

Daher der Ansatz über die Datei-ACLs für die drei Dateien.

Was die Vererbung angeht - wo soll das Recht herkommen dass dem Nutzer das löschen erlaubt? Warum muss die Vererbung da unterbrochen werden?

da ansonsten in einem Unterordner abgelegte Updates nicht mehr gelöscht werden würden

Was man wieder mit einer angepassten ACL für diesen Ordner regeln könnte. Alles nur Ausrede ...

Und genau das ist das wichtige:

Wenn ein Benutzer für einen Ordner ...

Löschen einer Datei ist eine Operation auf dem Verzeichnis.
Bei der Datei das Löschen zu verweigern ist uninteressant und wird nicht beachtet (wie festgestellt wurde und auch im Zitat von skybird so drinsteht).

you can delete the file or folder if you are granted Delete Subfolders and Files permissions on the parent folder

Im Ordner muß man das Löschen verweigern (wie emeriks auch erfolgreich getestet hat).

Ergo: Löschen im Ordner erlauben und auf einer einzelnen Datei verweigern geht nicht.

Wenn er es getestet hätte - hat er aber nicht.

Der Nutzer hat KEINE Schreibrechte auf dem Ordner wie mein Screenshot schon zeigt (geerbt - Lesen, Ausführen). Der Nutzer soll und darf KEINE zusätzlichen Dateien ausser jenen drei ändern können.

Die "Lösung" von emeriks erlaubt aber genau dieses. Entsprechend ist es keine Lösung.

Nochmal der Vollständigkeit halber. Ein Ordner ohne Schreibrechte soll drei Dateien enthalten die geändert, aber nicht gelöscht werden können. Andere in dem Ordner enthaltene Dateien sollen ausschliesslich gelesen werden können.

Sobald die Datei selber "Änderrechte" hat (siehe Screenshot) - "Löschverweigerung hier geerbt vom Überordner" kann der NUTZER die Datei löschen.

Wenn er es getestet hätte - hat er aber nicht.

Redest Du jetzt von Dir selbst in der Dritten Person?

Du hast sicherlich folgendes überlesen:

Für die vorhandenen Dateien (EXE, DLL usw.), welche nicht geändert werden dürfen, die beiden letztgenannten Rechte je Datei einzeln verweigern.

Da das i.A. begrenzt viele sind, ist das von Hand oder mit einer Batch schnell erledigt.

Schon mal über Symbolic Links nachgedacht? Hiermit könnte Er z.B. Sub-Ordner an andere Stellen auslagern, wo die Vererbung nicht mehr greift. Aber dazu müsste Er testen ...

Emeriks - versucht du absichtlich meine Aussagen bzw. Screenshots zu ignorieren?

Deine Vorschlag erlaubt, dass NEUE Dateien in dem Ordner erzeugt werden. Dies kann der Nutzer derzeit nicht (und das ist auch gut so).

Getreu deines Vorschlages kommt das "Darf nicht löschen Recht" laut Screenshot nun vom Überordner - der Nutzer kann die Datei trotzdem löschen.

PS: Er bezog sich auf "(wie emeriks auch erfolgreich getestet hat)." da ich nicht auf deinen Post geantwortet habe.

Was ja auch klar ist, denn das "Ändern" Recht beinhaltet das Löschen, habe ich ja schon ganz oben gepostet, man sehe sich doch bitte mal folgende Tabelle an:
https://technet.microsoft.com/en-us/library/cc732880(v=ws.11).aspx
p.s. Du kannst einzelne Rechte granular vergeben, das "Ändern" ist ein ganzer "Satz" an Berechtigungen.

Was Du eingestellt hast, ist mir eigentlich egal. Ich habe Dir ein Beispiel genannt, welches genauso funktioniert, wie ich es geschrieben habe. Das habe ich gestern extra für Dich getestet (obwohl schon 100mal gemacht), ob Du mir das nun glaubst oder nicht. Auch egal.

Eine Software schreibt seine Lizenzprüfung (license.zip) in sein Programmverzeichnis, entpackt sie und löscht sie anschliessend wieder.
Ich möchte dem Nutzer gerne verweigern in dem Programmverzeichnis zu schreiben, muss allerdings eben jene License.zip erlauben.

Das Schreiben aller Dateien kann man damit nicht verhindern. Korrekt.
Aber das Programm kann dann die Lizenzdatei schreiben, nur diese nicht wieder löschen. Aber immer wieder überschreiben (neu füllen), sofern es nicht "löschen und neu erstellen" anwendet. Dann würde es wieder nicht gehen.
Wie Du alle anderen Dateien vor Überschreiben schützen kannst, habe ich schon geschrieben.

Vielleicht hilft Dir aber auch das weiter. (Lass Dich nicht von "Vista" abschrecken. Das Prinzip gilt immer noch.) Dort wird u.a. beschrieben, wie über die Virtualsierung der Schreibzugriffe bei aktiviertem UAC ein Benutzer ohne Adminrechte auch in Ordner unterhalb von Programme schreiben kann.
Kannst gerne auch mal den Disput zwischen DerWoWusste und mir zu UAC in diesem Thread lesen. Vielleicht bringts was.

Ich weiß nicht genau was dich motiviert mir immer wieder den Vorschlag zu unterbreiten welcher für mich NICHT funktioniert.
Es ist sehr nett von dir, dass du eine Lösung testest die so funktioniert wie DU es willst, die aber nicht abbildet was ich benötige.

Wenn der Nutzer allgemeine Schreibrechte in dem Ordner hat ist die Aufgabe verfehlt. Ob er bestimmte Dateien dort nicht ändern kann (wie in deinem Vorschlag) spielt keine Rolle wenn er einfach neue erstellt.

Für alle anderen:

Laut Microsoft ist die Reihenfolge der Anwendung der ACLs

Explicit Deny
Explicit Allow
Inherited Deny
Inherited Allow

Das heißt jedes Recht gezielt für die Datei überschreibt einfach die vererbten Rechte. Entsprechend ist der Ordner-ACL-Ansatz unwirksam. So weit so schlecht.

Nun scheiter ich gedanklich allerdings daran warum dann der erste Ansatz nicht funktioniert - also gezielt auf die Datei Löschen verweigern zu setzen. Die hätte als Dateispezifischer Deny dann ja die höchste Priorität. Dann wird es als effektives Recht auch angezeigt, löschen lässt sie sich trotzdem.
Dies bezieht sich auf auf den "Ändern" Eintrag. Hier sollte der Deny ebenfalls Priorität haben. Wenn beide existieren dürfte ein Löschen nicht möglich sein.

Ich weiß nicht genau was dich motiviert

Niemals aufgeben!

Mal im Ernst. Der Vorschlag mit den Symbolic Links, Umleitungen auf Share und/oder andere Platte, möglicherweise auch im Zusammenhang mit Windows 2012 und FSRM, könnte Deinem Traum verdammt nah kommen.

Einfach so, wie Du es schreibst, geht es definitiv nicht. Und wenn Dir das klar ist, Du an keinen anderen Lösungswegen interessiert bist, dann kannst Du diese Frage doch schließen?

Nochmal der Vollständigkeit halber. Ein Ordner ohne Schreibrechte soll drei Dateien enthalten die geändert, aber nicht gelöscht werden können. Andere in dem Ordner enthaltene Dateien sollen ausschliesslich gelesen werden können.

Ich weiß nicht wo dein Problem liegt. Das geht hier absolut problemlos. Ich hatte dir ja oben schon den Hinweis zum Ändern Recht gegeben.

Hier mein Test:

OrdnerX 
  |__ DateiA 

Rechte:

OrdnerX = (Alle Benutzer haben nur Lese- und Ausführrechte, alles normale Berechtigungen nur die also nur die Vererbten Rechte)
DateiA = (User Z gebe ich hier nun explizit nicht "Ändern" Rechte sondern nur die Schreibrechte ohne das Löschrecht in den erweiterten Einstellungen!! Also nur Lesen, Schreiben, Ausführen nicht Ändern)

Klappt einwandfrei. User Z kann die Datei beschreiben aber die Datei selbst nicht löschen. Andere ändern sowieso erst recht nicht.

Hi @129413,
ich kann das so aber auch nicht bestätigen. Das funktioniert nur solange, wie ich das mit einem Admin-User teste, der aber laut ACL auch gar keine anderen Rechte explizit für Admins oder für Ihn bekommt.
Teste ich das mit einem Benutzer, der kein Admin ist, dann geht das schon nicht mehr.

Der Haken ist der, dass der Nicht-Admin die Datei zwar öffnen kann, bearbeiten und dann auch wieder speichern. Er kann aber diese Datei nicht mit einer neuen Datei etwa via "speichern unter" aus einem Programm überschreiben. Er kann auch keine mit gleichem Namen drüber kopieren.

Ein Admin-User kann diese beiden Aktionen. Habe die Rechte so eingeschränkt, dass auch der Admin dort nicht erstellen kann. Keine Dateien ändern oder löschen. Nur für die eine explit Schreiben ohne Löschen erlaubt. Er kann sie öffnen, bearbeiten, abspeichern. Er kann sie durch Kopie ersetzen. Er kann sie via "speichern unter" mit einer anderen Datei überschreiben. Der Nicht-Admin kann das alles nicht. Nur wenn er die Datei direkt zum Bearbeiten öffnet.

Es hängt also jetzt davon ab, wie ein Programm sich verhält, wenn eine Datei bereits vorhanden ist, welche nicht da sein sollte, weil das Programm diese ja immer gleich wieder löschen will. Und wie es sich verhält, wenn es diese Datei nicht löschen kann.

Getestet mit Notepad.exe

Teste ich das mit einem Benutzer, der kein Admin ist, dann geht das schon nicht mehr.

Geht hier einwandfrei mit einem unprivilegierten Nutzer (Windows 7/8/10) bei "einfachem" schreiben in die Datei (ohne Umbenenn/oder Lösch-Methodik -> Notepad)

Es hängt also jetzt davon ab, wie ein Programm sich verhält,

Genau, z.B. bei Office-Dateien verhält es sich ja das diese erst die Daten in eine temporäre Datei speichern dann die originale Löschen und die temporäre wieder umbenennen.
Kommt also drauf an wie sich sein Programm verhält, bzw. was dieses mit den Files anstellen will.

Geht hier einwandfrei mit einem unprivilegierten Nutzer (Windows 7/8/10) bei "einfachem" schreiben in die Datei (ohne Umbenenn/oder Lösch-Methodik -> Notepad)

Du fängst eine neue, leere Datei an, und kannst sie dann mit "speichern unter" auf die vorhandene Datei speichern? (bei der, wo es erlaubt ist)
Oder öffnest Du die vorhandene, bearbeitest sie, uns speicherst dann?

Oder öffnest Du die vorhandene, bearbeitest sie, uns speicherst dann?

Genau das, ich vergebe die Rechte auf eine existierende Datei die der User dann beschreiben aber nicht aus dem Dateisystem löschen kann, mehr wollte der TO laut seinem Statement doch nicht.
Ich zitiere:

Ein Ordner ohne Schreibrechte soll drei Dateien enthalten die geändert, aber nicht gelöscht werden können.

Daraus leite ich jetzt ab das sie schon existieren.

Jetzt kommt's ja nur noch drauf an wie geht sein Programm mit den Berechtigungen um, reichen sie ihm oder eben nicht, wie du ja auch schon geschrieben hast.

Aaaalso - ich habe die Dateien nochmals als Platzhalter erstellt.

Rechte derzeit Lesen, Ausführen, Schreiben - Löschen wird verweigert. Dies funktioniert im Zusammenspiel mit dem Programm so tatsächlich. Es findet die Updates und die Lizenz, die Dateien werden geändert, aber nicht wieder gelöscht.

Offensichtlich gibt es einen Bug, wenn sowohl der "Ändern zugelassen" als auch "Löschen Verweigert" existiert - eigentlich sollte Zweiteres vorrangig behandelt werden.

Das Programm selber scheint keine Probleme zu haben wenn es nicht löschen kann.

Nun wollte ich die Dateien noch vor Admins schützen - dies funktioniert allerdings nicht da. Wenn ich die Vererbung für den Überordner aufhebe und dort Löschen verweigere erben darunterliegende Dateien dennoch "Vollzugriff". Wie kann das sein?

Ich geh hier noch am Krückstock....

Testordner, alle Rechte entfernt - nur Dom-Admin bekommt Rechte minus Löschen. Unterordner erstellt, erbt die Rechte. Besitzer ist jemand anderes (um Besitzerrechte auszuschliessen). Und dennoch kann ich ihn problemlos löschen *zeter*