Discussion:
Mal wieder: Rekursive Pfade "Anwendungsdaten\..."
(zu alt für eine Antwort)
Christoph Maercker
2011-09-16 12:37:33 UTC
Permalink
Hallo,

... diesmal unter Win2008R2. Welche Rechte mussten zur Behebung nochmal
verweigert werden? Eingestellt sind schon Lesen und "Ordnerinhalte
anzeigen" auf Verweigern für Jeder, direkt für das Verzeichnis
"Anwendungsdaten". Ist allerdings so ein Linkordner und über
"Eigenschaften" nicht erkennbar, wohin er wirklich verweist.

Der Pfad ist \Users\<username>\AppData\Local\Anwendungsdaten\...

Ich nehme stark an, der Nutzer wurde ganz simpel und vorschriftsmäßig
von der Firma angelegt, die den Server installiert hat.
--
CU Christoph Maercker.
Hans-Peter Matthess
2011-09-16 12:55:23 UTC
Permalink
Post by Christoph Maercker
Der Pfad ist \Users\<username>\AppData\Local\Anwendungsdaten\...
Die Junction "Anwendungsdaten" ist kaputt. Sollte so aussehen:
Jeder:(DENY)(S,RD)
NT-AUTORITÄT\SYSTEM:(I)(OI)(CI)(F)
VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
fbi\hpm:(I)(OI)(CI)(F)

Wenn "Jeder:(DENY)(S,RD)" fehlt, kommt es zu den Endlosverschachtelungen im
Explorer. Müsste man also reparieren (Jeder -> Verweigern -> Ordner
auflisten, Daten lesen. Evtl. sind auch die Attribute der Junction
zusätzlich noch kaputt.
Post by Christoph Maercker
Ich nehme stark an, der Nutzer wurde ganz simpel und vorschriftsmäßig
von der Firma angelegt, die den Server installiert hat.
Ich weiß nicht, wie die Leute es immer schaffen, diese kaputten Junctions zu
erzeugen. Evtl. Schrottinstallationen durch fehlerhafte Images.
--
Scheinsicherheit und System-Zerstörung durch Virenscanner:
http://www.soehnitz.de/itsicherheit/virenscannersinnoderunsinn/index.html
Darum: http://www.soehnitz.de/itsicherheit/wassiewirklichbrauchen/index.html
Konfiguration einfach gemacht: http://home.arcor.de/skanthak/safer.html
Christoph Maercker
2011-09-16 13:58:17 UTC
Permalink
Post by Hans-Peter Matthess
Jeder:(DENY)(S,RD)
Exakt so eingestellt. Was lediglich den Explorer am Zugreifen hindert,
nicht aber andere Programme d.h. die Verweigerung greift seltsamerweise
nicht. Genau so kenne ich es bisher nur in Fällen, wo *keine*
Verweigerung vor Jeder eingetragen war.
Post by Hans-Peter Matthess
NT-AUTORITÄT\SYSTEM:(I)(OI)(CI)(F)
VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
Was in explorerüblicher Darstellung "Vollzugriff" = sämtliche Rechte
erlaubt bedeutet, oder?
Post by Hans-Peter Matthess
fbi\hpm:(I)(OI)(CI)(F)
Fehlt. Statt dessen ist $user mit Vollzugriff eingetragen.
Post by Hans-Peter Matthess
Wenn "Jeder:(DENY)(S,RD)" fehlt, kommt es zu den Endlosverschachtelungen im
Explorer. Müsste man also reparieren (Jeder -> Verweigern -> Ordner
auflisten, Daten lesen. Evtl. sind auch die Attribute der Junction
zusätzlich noch kaputt.
Sieht so aus.
Post by Hans-Peter Matthess
Post by Christoph Maercker
Ich nehme stark an, der Nutzer wurde ganz simpel und vorschriftsmäßig
von der Firma angelegt, die den Server installiert hat.
Ich weiß nicht, wie die Leute es immer schaffen, diese kaputten Junctions zu
erzeugen. Evtl. Schrottinstallationen durch fehlerhafte Images.
Nehme ich auch an. Wobei auf dem betr. Server nicht allzuviel in Frage
kommt:

- Acrobat Reader
- 7Zip
- Cisco VPN-Client
- Firefox 6.0 und
- hp OpenView, die Hauptanwendung.

hp-OV ist in Englisch, und scheidet damit als Verursacher weitgehend
aus, dgl. Cisco-VPN.
Außerdem MS-Virtual C++ 2005, das käme natürlich auch als Verursacher in
Frage. ;-)

Mozilla und/oder Adobe legen evtl. die (nicht rekursive) Junction
\Users\<username>\Anwendungsdaten
an, die dann auf
\Users\<username>\AppData\Local\
verweist. Wer dort drin nochmals "Anwendungsdaten" anlegt und wozu, weiß
der Geier. Die AppDaten der beiden o.g. Progs liegen Z.Zt. nur beim User
\Users\Administrator\AppData\Local\
an Der hat ebenfalls das o.g. rekursive Verzeichnis "Anwendungsdaten",
unter \Program Data habe ich eben noch eins gefunden. Die "Installer"
leisten mal wieder ganze Arbeit. :-\

BTW: Kann in den Userprofilen ein *echtes* Verzeichnis "Anwendungsdaten"
angelegt werden oder verhindert Win7 das? Sonst hieße das, die
Programmierer mind. einer der o.g. Anwendung hätten zwar mal was von
Junctions gehört und sie in ihren Installern beigebracht, welche
anzulegen, kennen deren Funktionsweise aber ebenso wenig wie die meisten
Windows-Nutzer. Ältere Installer, die das Junction-Konzept noch nicht
kennen, würden ja versuchen, die betr. Verzeichnisse in echt anzulegen.
Falls sie nicht schlau genug sind, die betr. Systemvariable abzufragen
und das machen meiner Erfahrung nach ziemlich viele nicht.
--
CU Christoph Maercker.
Hans-Peter Matthess
2011-09-16 15:57:58 UTC
Permalink
Post by Christoph Maercker
Post by Hans-Peter Matthess
Jeder:(DENY)(S,RD)
Exakt so eingestellt. Was lediglich den Explorer am Zugreifen hindert,
Dann ist es ja ok. Es hindert alle Programme an dem in der Verweigerung
eingestellten Zugriff, nicht nur den Explorer.
Post by Christoph Maercker
nicht aber andere Programme d.h. die Verweigerung greift seltsamerweise
nicht.
Doch, die Verweigerung greift natürlich für alle anderen Programme auch,
was eben *genau diese Verweigerung" betrifft. Es hindert Programme
allerdings nicht daran, zum Ziel der Junction zu springen, sonst würde die
Junction ja nicht funktionieren. Einige Dateimanager machen das auch so.
Sie können die Junction ebenfalls nicht öffnen, wie auch der Explorer, aber
sie zeigen das Ziel an. Welche "Anderen Programme" sind das denn und was
genau passiert da? Welche Fehler zeigen sich?
Post by Christoph Maercker
Genau so kenne ich es bisher nur in Fällen, wo *keine*
Verweigerung vor Jeder eingetragen war.
Du bist im Moment nur etwas verwirrt. ;-)
Post by Christoph Maercker
Post by Hans-Peter Matthess
NT-AUTORITÄT\SYSTEM:(I)(OI)(CI)(F)
VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
Was in explorerüblicher Darstellung "Vollzugriff" = sämtliche Rechte
erlaubt bedeutet, oder?
Ja
Post by Christoph Maercker
Post by Hans-Peter Matthess
fbi\hpm:(I)(OI)(CI)(F)
Fehlt. Statt dessen ist $user mit Vollzugriff eingetragen.
Nö, hpm ist ja $user, mein Useraccount.
Post by Christoph Maercker
Mozilla und/oder Adobe legen evtl. die (nicht rekursive) Junction
\Users\<username>\Anwendungsdaten
an, die dann auf
\Users\<username>\AppData\Local\
verweist. Wer dort drin nochmals "Anwendungsdaten" anlegt und wozu, weiß
der Geier.
Nö, all diese Junctions werden vom Windows-Setup bei der Installation
eingerichtet. Programme legen keine an.
Post by Christoph Maercker
BTW: Kann in den Userprofilen ein *echtes* Verzeichnis "Anwendungsdaten"
angelegt werden oder verhindert Win7 das?
Wenn man die gleichnamige Junction löscht, kann man das, aber das wäre doch
grober Unfug. %Appdata% existiert doch.
Post by Christoph Maercker
Sonst hieße das, die
Programmierer mind. einer der o.g. Anwendung hätten zwar mal was von
Junctions gehört und sie in ihren Installern beigebracht, welche
anzulegen,
Wie gesagt, ich kenne keine Anwendung, die Junctions erzeugt.
Post by Christoph Maercker
kennen deren Funktionsweise aber ebenso wenig wie die meisten
Windows-Nutzer. Ältere Installer, die das Junction-Konzept noch nicht
kennen, würden ja versuchen, die betr. Verzeichnisse in echt anzulegen.
Falls sie nicht schlau genug sind, die betr. Systemvariable abzufragen
und das machen meiner Erfahrung nach ziemlich viele nicht.
Die Junctions sind ja aus Gründen der Abwärtskompatibilität da.
Wenn ein altes Programm fest auf "Anwendungsdaten" verdrahtet ist, wird es
von der Junction an den richtigen Ort umgeleitet. Im Grunde kann man die
Junctions alle löschen. Die Programme, die dann nicht mehr funktionieren,
sind kaputter Schrott. Durch aktuelle ersetzen.
--
Scheinsicherheit und System-Zerstörung durch Virenscanner:
http://www.soehnitz.de/itsicherheit/virenscannersinnoderunsinn/index.html
Darum: http://www.soehnitz.de/itsicherheit/wassiewirklichbrauchen/index.html
Konfiguration einfach gemacht: http://home.arcor.de/skanthak/safer.html
Christoph Maercker
2011-09-19 09:58:05 UTC
Permalink
Post by Hans-Peter Matthess
Dann ist es ja ok. Es hindert alle Programme an dem in der Verweigerung
eingestellten Zugriff, nicht nur den Explorer.
In den Fällen, wo ich bisher die Rechte so eingestellt habe, ja.
Post by Hans-Peter Matthess
Doch, die Verweigerung greift natürlich für alle anderen Programme auch,
was eben *genau diese Verweigerung" betrifft. Es hindert Programme
allerdings nicht daran, zum Ziel der Junction zu springen, sonst würde die
Junction ja nicht funktionieren. Einige Dateimanager machen das auch so.
Sie können die Junction ebenfalls nicht öffnen, wie auch der Explorer, aber
sie zeigen das Ziel an. Welche "Anderen Programme" sind das denn und was
genau passiert da? Welche Fehler zeigen sich?
Die Rekursionen bleiben bzw. kommen wieder, sobald ich das Verzeichnis
nach $irgendwohin wechsle und wieder zurückkehre. Siehe mein
Post by Hans-Peter Matthess
Post by Christoph Maercker
Genau so kenne ich es bisher nur in Fällen, wo *keine*
Verweigerung vor Jeder eingetragen war.
Du bist im Moment nur etwas verwirrt. ;-)
Hm, auf meinem Dienst-PC hatte ich Junctions, die Rekursionen erzeugt
haben, kurzerhand mit Sysinternals Junction.exe gelöscht, bisher ohne
Post by Hans-Peter Matthess
Post by Christoph Maercker
Post by Hans-Peter Matthess
NT-AUTORITÄT\SYSTEM:(I)(OI)(CI)(F)
VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
Auch damit bin ich die Rekursionen losgeworden. Auf dem 2008-System
bleiben die Rekursionen, trotz verweigerter Rechte.
Post by Hans-Peter Matthess
Nö, all diese Junctions werden vom Windows-Setup bei der Installation
eingerichtet. Programme legen keine an.
Ändern aber evtl. die Rechte? Sonst wüsste ich nicht, wie es zu den
rekursiven Verzeichnissen kommen kann, es sei denn, der
Windows-Installer produziert sie unter bestimmten Bedingungen.
Post by Hans-Peter Matthess
Post by Christoph Maercker
BTW: Kann in den Userprofilen ein *echtes* Verzeichnis "Anwendungsdaten"
angelegt werden oder verhindert Win7 das?
Wenn man die gleichnamige Junction löscht, kann man das, aber das wäre doch
grober Unfug. %Appdata% existiert doch.
Natürlich, aber Installer, die noch keine Junctions kennen, würden evtl.
genau das machen. Beileibe nicht alle sind so schlau, %AppData% zu
Post by Hans-Peter Matthess
Die Junctions sind ja aus Gründen der Abwärtskompatibilität da.
Wenn ein altes Programm fest auf "Anwendungsdaten" verdrahtet ist, wird es
von der Junction an den richtigen Ort umgeleitet. Im Grunde kann man die
Junctions alle löschen. Die Programme, die dann nicht mehr funktionieren,
sind kaputter Schrott. Durch aktuelle ersetzen.
Leuchtet ein. Auf dem W2008-Server, um den es geht, kann ich die
Junctions mit gutem Gewissen killen, dort wird nur eine wichtige und
aktuelle Anwendung laufen. Muss zum Löschen von Junctions so was wie das
o.g. Tool von Sysinternals verwendet werden? Einfach mit DEL-Taste
kriegt man sie WIMRE nicht weg.
--
CU Christoph Maercker.
Hans-Peter Matthess
2011-09-19 11:16:38 UTC
Permalink
Post by Christoph Maercker
Post by Hans-Peter Matthess
Dann ist es ja ok. Es hindert alle Programme an dem in der Verweigerung
eingestellten Zugriff, nicht nur den Explorer.
In den Fällen, wo ich bisher die Rechte so eingestellt habe, ja.
Die Junctions haben aber alle identische Rechte. Wenn man erst etwas
einstellen muss, ist schon der Wurm drin.
Post by Christoph Maercker
Post by Hans-Peter Matthess
Doch, die Verweigerung greift natürlich für alle anderen Programme auch,
was eben *genau diese Verweigerung" betrifft. Es hindert Programme
allerdings nicht daran, zum Ziel der Junction zu springen, sonst würde die
Junction ja nicht funktionieren. Einige Dateimanager machen das auch so.
Sie können die Junction ebenfalls nicht öffnen, wie auch der Explorer, aber
sie zeigen das Ziel an. Welche "Anderen Programme" sind das denn und was
genau passiert da? Welche Fehler zeigen sich?
Die Rekursionen bleiben bzw. kommen wieder, sobald ich das Verzeichnis
nach $irgendwohin wechsle und wieder zurückkehre. Siehe mein
Ja, das ist mir allerdings zu allgemein und nebulös gehalten. Nichts, was
man exakt nachvollziehen könnte. Ich kann weder in Anwendungen noch in
der Konsole Rekursionen erzeugen. Ich hatte ja schon mal nach einer exakt
nachvollziehbaren Befehlsfolge gefragt.
Post by Christoph Maercker
Post by Hans-Peter Matthess
Post by Christoph Maercker
Genau so kenne ich es bisher nur in Fällen, wo *keine*
Verweigerung vor Jeder eingetragen war.
Du bist im Moment nur etwas verwirrt. ;-)
Hm, auf meinem Dienst-PC hatte ich Junctions, die Rekursionen erzeugt
haben, kurzerhand mit Sysinternals Junction.exe gelöscht,
Ein Klick auf "Löschen" tut's auch.
Post by Christoph Maercker
bisher ohne
ärgerliche Nebenwirkungen.
Eben, einfach weg damit, Problem erledigt. ;-)
Post by Christoph Maercker
Post by Hans-Peter Matthess
Nö, all diese Junctions werden vom Windows-Setup bei der Installation
eingerichtet. Programme legen keine an.
Ändern aber evtl. die Rechte?
Wenn es ein Programm gäbe, das sowas machte, müsste dieses nach Löschen der
Junction ja eigentlich nicht mehr funktionieren.
--
Scheinsicherheit und System-Zerstörung durch Virenscanner:
http://www.soehnitz.de/itsicherheit/virenscannersinnoderunsinn/index.html
Darum: http://www.soehnitz.de/itsicherheit/wassiewirklichbrauchen/index.html
Konfiguration einfach gemacht: http://home.arcor.de/skanthak/safer.html
Christoph Maercker
2011-09-20 09:08:36 UTC
Permalink
Post by Hans-Peter Matthess
Die Junctions haben aber alle identische Rechte. Wenn man erst etwas
einstellen muss, ist schon der Wurm drin.
Die Rechte scheinen sogar zu stimmen, alle Verzeichnisse, die ich
überprüft hatte waren für Jeder zum Lesen und Scannen gesperrt. Trotzdem
können Anwendungen, WIMRE sogar cmd.exe in diese Junctions bis zur
Unendlichkeit reinschauen.
Post by Hans-Peter Matthess
Post by Christoph Maercker
Die Rekursionen bleiben bzw. kommen wieder, sobald ich das Verzeichnis
nach $irgendwohin wechsle und wieder zurückkehre. Siehe mein
Ja, das ist mir allerdings zu allgemein und nebulös gehalten. Nichts, was
man exakt nachvollziehen könnte. Ich kann weder in Anwendungen noch in
der Konsole Rekursionen erzeugen. Ich hatte ja schon mal nach einer exakt
nachvollziehbaren Befehlsfolge gefragt.
Beantwortet hatte ich Deine Frage mit Verzeichnisauszügen, z.B. am
01.07., generiert mit windowseigener cmd.exe:

z.B. hier:
Datenträger in Laufwerk C: ist xxx
Verzeichnis von c:\Users\All
Users\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\ ...

29.04.2011 14:54 <DIR> Adobe
06.04.2011 14:42 <DIR> Windows Genuine Advantage

Genauso sieht es momentan auf dem W2008-Server aus, trotz korrekt
gesetzter Rechte. Und es sind wie Du siehst nicht nur Fremdprogramme,
sondern auch M$-eigene, die solche Rekursionen produzieren.
Post by Hans-Peter Matthess
Ein Klick auf "Löschen" tut's auch.
Im Explorer, wohlgemerkt. Andere Filemanager verrecken an den Rekursionen.
Post by Hans-Peter Matthess
Eben, einfach weg damit, Problem erledigt. ;-)
Auf dem W2008-System habe ich es inzwischen so gemacht.
Post by Hans-Peter Matthess
Post by Christoph Maercker
Post by Hans-Peter Matthess
Nö, all diese Junctions werden vom Windows-Setup bei der Installation
eingerichtet. Programme legen keine an.
Ändern aber evtl. die Rechte?
Wenn es ein Programm gäbe, das sowas machte, müsste dieses nach Löschen der
Junction ja eigentlich nicht mehr funktionieren.
Würde mich nicht wundern. Ist bisher aber noch nicht passiert und wird
auf dem 2008er hoffentlich auch nicht.
--
CU Christoph Maercker.
Hans-Peter Matthess
2011-09-20 11:05:49 UTC
Permalink
Post by Christoph Maercker
Post by Hans-Peter Matthess
Die Junctions haben aber alle identische Rechte. Wenn man erst etwas
einstellen muss, ist schon der Wurm drin.
Die Rechte scheinen sogar zu stimmen, alle Verzeichnisse, die ich
überprüft hatte waren für Jeder zum Lesen und Scannen gesperrt. Trotzdem
können Anwendungen, WIMRE sogar cmd.exe in diese Junctions bis zur
Unendlichkeit reinschauen.
Nur in der Form, wie von Melanchthon hier beschrieben:
http://blogs.technet.com/dmelanchthon/archive/2006/11/24/kein-zugriff-auf-verzeichnisse-unter-windows-vista.aspx
Post by Christoph Maercker
Post by Hans-Peter Matthess
Post by Christoph Maercker
Die Rekursionen bleiben bzw. kommen wieder, sobald ich das Verzeichnis
nach $irgendwohin wechsle und wieder zurückkehre. Siehe mein
Ja, das ist mir allerdings zu allgemein und nebulös gehalten. Nichts, was
man exakt nachvollziehen könnte. Ich kann weder in Anwendungen noch in
der Konsole Rekursionen erzeugen. Ich hatte ja schon mal nach einer exakt
nachvollziehbaren Befehlsfolge gefragt.
Beantwortet hatte ich Deine Frage mit Verzeichnisauszügen, z.B. am
Datenträger in Laufwerk C: ist xxx
Verzeichnis von c:\Users\All
Users\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\ ...
29.04.2011 14:54 <DIR> Adobe
06.04.2011 14:42 <DIR> Windows Genuine Advantage
Ja, aber da fehlt schon wieder der von mir NACHVOLLZIEHBARE BEFEHL, der
obige Ausgabe erzeugte. ;-) Ich muss doch, um etwas nachvollziehen zu
können, erstens wissen, wo ich mich befinde und zweitens wissen, was ich
eingeben soll. Beispiel hier:

Ich befinde mich in "C:\Users\hpm\AppData\Local" und gebe da ein:
"dir Anwendungsdaten"
-------------------------------
C:\Users\hpm\AppData\Local>dir Anwendungsdaten
Verzeichnis von C:\Users\hpm\AppData\Local\Anwendungsdaten
Datei nicht gefunden
-------------------------------------
Also keine Rekursion, sondern "Datei nicht gefunden".
Ein Blick direkt in "Anwendungsdaten" geht nicht.
Da aber die Junction "Anwendungsdaten" auf das Verzeichnis zeigt, in dem sie
sich befindet, klappt dies hier:
"dir Anwendungsdaten\Microsoft"
------------------------------------
C:\Users\hpm\AppData\Local>dir Anwendungsdaten\Microsoft
Verzeichnis von C:\Users\hpm\AppData\Local\Anwendungsdaten\Microsoft
17.09.2011 12:50 <DIR> .
17.09.2011 12:50 <DIR> ..
19.10.2009 18:06 <DIR> Assistance
19.09.2011 19:16 <DIR> Device Metadata
19.10.2009 15:12 <DIR> Event Viewer
12.09.2011 18:47 <DIR> Feeds
usw...
---------------------------------------
Die Junction funktioniert also wie erwartet.
Von der Ebene aus wäre "Dir Microsoft" natürlich einfacher gewesen.
Post by Christoph Maercker
Post by Hans-Peter Matthess
Ein Klick auf "Löschen" tut's auch.
Im Explorer, wohlgemerkt. Andere Filemanager verrecken an den Rekursionen.
Welcher Filemanager denn z.B.? Ich habe hier etliche parat, bei keinem
Rekursionen. Moderne Dateimanager springen entweder zum Ziel der Junction,
was keine Rekursionen ergibt oder bringen ein "Zugriff verweigert" wie der
Windows-Explorer.
--
Scheinsicherheit und System-Zerstörung durch Virenscanner:
http://www.soehnitz.de/itsicherheit/virenscannersinnoderunsinn/index.html
Darum: http://www.soehnitz.de/itsicherheit/wassiewirklichbrauchen/index.html
Konfiguration einfach gemacht: http://home.arcor.de/skanthak/safer.html
Christoph Maercker
2011-09-20 16:03:31 UTC
Permalink
Post by Hans-Peter Matthess
http://blogs.technet.com/dmelanchthon/archive/2006/11/24/kein-zugriff-auf-verzeichnisse-unter-windows-vista.aspx
Danke, sehe ich mir morgen an.
Post by Hans-Peter Matthess
Post by Christoph Maercker
Datenträger in Laufwerk C: ist xxx
Verzeichnis von c:\Users\All
Users\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\ ...
...
Post by Hans-Peter Matthess
Ja, aber da fehlt schon wieder der von mir NACHVOLLZIEHBARE BEFEHL,
"dir Anwendungsdaten"
-------------------------------
C:\Users\hpm\AppData\Local>dir Anwendungsdaten
Verzeichnis von C:\Users\hpm\AppData\Local\Anwendungsdaten
Datei nicht gefunden
-------------------------------------
Also keine Rekursion, sondern "Datei nicht gefunden".
Just so habe ich obigen Output produziert:
cd anwend*
cd anwend*
cd anwend*
cd anwend*
...
dir anwend* > dir.txt
Post by Hans-Peter Matthess
Ein Blick direkt in "Anwendungsdaten" geht nicht.
Auf "befallenen" System geht der sehr gut. ;-)
Post by Hans-Peter Matthess
Da aber die Junction "Anwendungsdaten" auf das Verzeichnis zeigt, in dem sie
"dir Anwendungsdaten\Microsoft"
------------------------------------
C:\Users\hpm\AppData\Local>dir Anwendungsdaten\Microsoft
Verzeichnis von C:\Users\hpm\AppData\Local\Anwendungsdaten\Microsoft
17.09.2011 12:50<DIR> .
17.09.2011 12:50<DIR> ..
19.10.2009 18:06<DIR> Assistance
19.09.2011 19:16<DIR> Device Metadata
19.10.2009 15:12<DIR> Event Viewer
12.09.2011 18:47<DIR> Feeds
usw...
---------------------------------------
Die Junction funktioniert also wie erwartet.
Stimmt so würde ich es erwarten. Auf meinem Home-PC überprüfe ich das
dieser Tage mal. Dort gab es zumindest an dem Tag als ich die Rechte für
Jeder verweigert hatte, keine Rekursionen mehr.
Post by Hans-Peter Matthess
Post by Christoph Maercker
Im Explorer, wohlgemerkt. Andere Filemanager verrecken an den Rekursionen.
Welcher Filemanager denn z.B.? Ich habe hier etliche parat, bei keinem
Rekursionen. Moderne Dateimanager springen entweder zum Ziel der Junction,
was keine Rekursionen ergibt oder bringen ein "Zugriff verweigert" wie der
Windows-Explorer.
z.B. Total Commander v7.50a, aber bei Systemen, wo es auftritt, eben
auch CMD.exe. Als ich auf dem 2008-Server in einem der betr.
Verzeichnisse "DEL /S Anwendungsdaten" eingegeben habe, kam prompt die
Frage, ob auch das gleichnamige Unterverzeichnis gelöscht werden soll.
Ich habe an der Stelle sicherheitshalber mit "n" geantwortet.
--
CU Christoph Maercker.
Hans-Peter Matthess
2011-09-20 23:40:56 UTC
Permalink
Post by Christoph Maercker
Post by Hans-Peter Matthess
Post by Christoph Maercker
Users\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\ ...
...
Post by Hans-Peter Matthess
Ja, aber da fehlt schon wieder der von mir NACHVOLLZIEHBARE BEFEHL,
Da kann man aber jede Menge netter Befehle eingeben. Hätte ja auch etwas
mit dir /s... sein können...
Post by Christoph Maercker
Post by Hans-Peter Matthess
"dir Anwendungsdaten"
-------------------------------
C:\Users\hpm\AppData\Local>dir Anwendungsdaten
Verzeichnis von C:\Users\hpm\AppData\Local\Anwendungsdaten
Datei nicht gefunden
-------------------------------------
Also keine Rekursion, sondern "Datei nicht gefunden".
cd anwend*
cd anwend*
cd anwend*
cd anwend*
Das ist klar, das kann man beliebig treiben, ist auch durch Rechte nicht
untersagt, fragt sich allerdings, warum man sowas Sinnloses tun sollte.
In keinem der Anwend* kann irgendwas angezeigt werden.
...
Post by Christoph Maercker
dir anwend* > dir.txt
Da kommt dann halt immer "Datei nicht gefunden".
Post by Christoph Maercker
Post by Hans-Peter Matthess
Ein Blick direkt in "Anwendungsdaten" geht nicht.
Auf "befallenen" System geht der sehr gut. ;-)
Ich dachte jetzt, du hättest eine Möglichkeit gefunden, auf Systemen mit
korrekten Junctions nachvollziehbar Rekursionen zu erzeugen.
Das obige Spiel mit "cd anwend*" ist zwar sowas, ich kenne aber kein
Programm oder keinen User, der sowas machen würde.
Ein "dir" direkt in Anwendungsdaten bringt halt kein Ergebnis, egal, wie oft
man es versucht. Nur mit kaputter Junction geht das.
Post by Christoph Maercker
Post by Hans-Peter Matthess
Da aber die Junction "Anwendungsdaten" auf das Verzeichnis zeigt, in dem sie
"dir Anwendungsdaten\Microsoft"
------------------------------------
C:\Users\hpm\AppData\Local>dir Anwendungsdaten\Microsoft
Verzeichnis von C:\Users\hpm\AppData\Local\Anwendungsdaten\Microsoft
17.09.2011 12:50<DIR> .
17.09.2011 12:50<DIR> ..
19.10.2009 18:06<DIR> Assistance
19.09.2011 19:16<DIR> Device Metadata
19.10.2009 15:12<DIR> Event Viewer
12.09.2011 18:47<DIR> Feeds
usw...
---------------------------------------
Die Junction funktioniert also wie erwartet.
Stimmt so würde ich es erwarten. Auf meinem Home-PC überprüfe ich das
dieser Tage mal. Dort gab es zumindest an dem Tag als ich die Rechte für
Jeder verweigert hatte, keine Rekursionen mehr.
OK
Post by Christoph Maercker
Post by Hans-Peter Matthess
Post by Christoph Maercker
Im Explorer, wohlgemerkt. Andere Filemanager verrecken an den Rekursionen.
Welcher Filemanager denn z.B.? Ich habe hier etliche parat, bei keinem
Rekursionen. Moderne Dateimanager springen entweder zum Ziel der Junction,
was keine Rekursionen ergibt oder bringen ein "Zugriff verweigert" wie der
Windows-Explorer.
z.B. Total Commander v7.50a, aber bei Systemen, wo es auftritt, eben
auch CMD.exe.
Der TC (hier 7.56a) springt immer zum Ziel, versucht nicht, die Junction zu
öffnen. Wenn man da auf "Anwendungsdaten" doppelklickt, tut sich gar nichts,
denn die Junction zeigt halt auf das Verzeichnis, in dem sie sich befindet
und das ja eh gerade schon angezeigt wird.
Beim Doppelklick auf "Dokumente und Einstellungen" springt er z.B. nach
"C:\Users". Ist die Junction kaputt, ist das Ergebnis aber
"C:\Dokumente und Einstellungen".
Post by Christoph Maercker
Als ich auf dem 2008-Server in einem der betr.
Verzeichnisse "DEL /S Anwendungsdaten" eingegeben habe, kam prompt die
Frage, ob auch das gleichnamige Unterverzeichnis gelöscht werden soll.
Ich habe an der Stelle sicherheitshalber mit "n" geantwortet.
Bei korrekter Junction kommt da wieder "nicht gefunden".
--
Scheinsicherheit und System-Zerstörung durch Virenscanner:
http://www.soehnitz.de/itsicherheit/virenscannersinnoderunsinn/index.html
Darum: http://www.soehnitz.de/itsicherheit/wassiewirklichbrauchen/index.html
Konfiguration einfach gemacht: http://home.arcor.de/skanthak/safer.html
Christoph Maercker
2011-09-22 08:02:57 UTC
Permalink
Post by Hans-Peter Matthess
Post by Christoph Maercker
cd anwend*
cd anwend*
cd anwend*
cd anwend*
Das ist klar, das kann man beliebig treiben, ist auch durch Rechte nicht
untersagt, fragt sich allerdings, warum man sowas Sinnloses tun sollte.
Diverse Datei-Suchprogramme scheinen es zu tun(, weil sie die Junctions
rekursiv sehen). Ohne die hätte ich den Bug gar nicht bemerkt.
Gelegentlich teste ich mal einen x-beliebigen Packer.
Post by Hans-Peter Matthess
In keinem der Anwend* kann irgendwas angezeigt werden.
Das schon, nur die Junctions werden mit DIR nicht mehr angezeigt, das
stimmt.

...
Post by Hans-Peter Matthess
Post by Christoph Maercker
dir anwend*> dir.txt
Da kommt dann halt immer "Datei nicht gefunden".
Bei verkürzten Verzeichnisnamen ja, nicht aber wenn er vollständig
angegeben wird:

j:\Users\weston\AppData\Local\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten>dir
anw*
Verzeichnis von
j:\Users\user\AppData\Local\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten

Datei nicht gefunden

j:\Users\weston\AppData\Local\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten>dir
anwendungsdaten

Verzeichnis von
j:\Users\user\AppData\Local\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\anwendungsdaten

22.09.2011 08:53 <DIR> .
22.09.2011 08:53 <DIR> ..
30.06.2011 10:53 <DIR> Adobe
15.09.2011 09:16 <DIR> assembly
15.09.2011 09:16 <DIR> Microsoft
27.05.2011 07:40 <DIR> Microsoft Help
29.06.2011 16:47 <DIR> MiKTeX
04.08.2011 15:47 7.595 Resmon.ResmonCfg
...
Post by Hans-Peter Matthess
Post by Christoph Maercker
Post by Hans-Peter Matthess
Ein Blick direkt in "Anwendungsdaten" geht nicht.
Auf "befallenen" System geht der sehr gut. ;-)
Ich dachte jetzt, du hättest eine Möglichkeit gefunden, auf Systemen mit
korrekten Junctions nachvollziehbar Rekursionen zu erzeugen.
Das obige Spiel mit "cd anwend*" ist zwar sowas, ich kenne aber kein
Programm oder keinen User, der sowas machen würde.
Dann dürften sich Dateisuchen, z.B. mit Total Commander nicht in solchen
Pseudo-Verzeichnisbäumen festfahren. Anscheindend sehen die bei einem
simplen Directory Scan mehr als DIR, sonst würden sie die rekursiven
Unterverzeichnisse nicht finden.
Post by Hans-Peter Matthess
Ein "dir" direkt in Anwendungsdaten bringt halt kein Ergebnis, egal, wie oft
man es versucht. Nur mit kaputter Junction geht das.
Demnach wäre die Junction auf dem oben "zitierten" System in Ordnung.
Blankes DIR zeigt die Junctions auch dort nur auf oberster Ebene an.
Post by Hans-Peter Matthess
Post by Christoph Maercker
z.B. Total Commander v7.50a, aber bei Systemen, wo es auftritt, eben
auch CMD.exe.
Der TC (hier 7.56a) springt immer zum Ziel, versucht nicht, die Junction zu
öffnen. Wenn man da auf "Anwendungsdaten" doppelklickt, tut sich gar nichts,
denn die Junction zeigt halt auf das Verzeichnis, in dem sie sich befindet
und das ja eh gerade schon angezeigt wird.
Auf manchen Systemen ja, auf anderen nicht. Auf dem 2008-System, um das
es im OP geht, jeweils nach dem Verweigern von Directory Scan, solange
das Verzeichnis nicht nach oben verlassen wurde.
Post by Hans-Peter Matthess
Beim Doppelklick auf "Dokumente und Einstellungen" springt er z.B. nach
"C:\Users". Ist die Junction kaputt, ist das Ergebnis aber
"C:\Dokumente und Einstellungen".
Stimmt, das habe ich bisher vergessen zu erwähnen: Die Rekursionen
wurden bisher ausschließlich bei "Anwendungsdaten" und "App Data"
beobachtet. Andere Junctions verhalten sich in der DOS-Box wie auch im
TC exakt so, wie ich erwarten würde und wie $Anwendungsgeraffel auf
manchen Systemen ebenfalls funktioniert:

cd \programme
j:\Programme>cd \programme
j:\Programme>cd \programme
j:\Programme>cd \programme
j:\Programme>
...

Allerdings sind die Berechtigungen von "Programme" etwas anders als bei
$Anwendungsgeraffel gesetzt:
"Ordnerinhalt auflisten/Lesen" unter "Spezielle Berechtigungen" wird
verweigert. Ich hatte bei $Anwendungsgeraffel die allgemein zugänglichen
Berechtigungen "Ordnerinhalt auflisten" + "Lesen" verweigert. Worin
besteht der Unterschied??
Post by Hans-Peter Matthess
Post by Christoph Maercker
Als ich auf dem 2008-Server in einem der betr.
Verzeichnisse "DEL /S Anwendungsdaten" eingegeben habe, kam prompt die
Frage, ob auch das gleichnamige Unterverzeichnis gelöscht werden soll.
Ich habe an der Stelle sicherheitshalber mit "n" geantwortet.
Bei korrekter Junction kommt da wieder "nicht gefunden".
Bei diesem System hat sich's durch Löschen per Commander erledigt. Beim
nächsten probiere ich mal, ob die "speziellen" den entscheidenden
Unterschied ausmachen.

BTW: Wieviele Admins blicken bei den NTFS-Rechten einklich durch? Wenn
ich das mit den schlappen 7+1 Rechten unter NetWare oder gar den 3x3
Rechten unter Linux/Unix vergleiche ... weil es doch immer heißt,
Windows wäre so einfach zu bedienen ...
Die Frage, ob auch User die NTFS-Rechte beherrschen, erübrigt sich schon
beinahe.
--
CU Christoph Maercker.
Robert Jasiek
2011-09-22 08:44:25 UTC
Permalink
Post by Christoph Maercker
Wieviele Admins blicken bei den NTFS-Rechten einklich durch?
Vermutlich fast niemand. War es Paul Thurrott, der schrieb, dass er 2
Jahre lang NTFS-Rechte studiert hätte, nur um dann einzusehen, dass
man sich besser auf die grundlegenden Lese-, Schreib- und
Ausführungsrechte beschränken solle?
Christoph Schmees
2011-09-22 09:09:44 UTC
Permalink
Post by Christoph Maercker
...
BTW: Wieviele Admins blicken bei den NTFS-Rechten einklich durch?
Wenn ich das mit den schlappen 7+1 Rechten unter NetWare oder gar
den 3x3 Rechten unter Linux/Unix vergleiche ... weil es doch
immer heißt, Windows wäre so einfach zu bedienen ...
Die Frage, ob auch User die NTFS-Rechte beherrschen, erübrigt
sich schon beinahe.
das "beinahe" kannst du getrost weglassen :-)

[Heisenberg und Planck diskutieren über die Unschärfe-Relation.
Planck meint, auf der ganzen Welt hätten nur drei Menschen die
Unschärfe-Relation verstanden. Darauf Heisenberg: Wer ist der
dritte?]

Wobei wir nicht ausschließen wollen, dass der eine oder andere
MCSE sich *tatsächlich* im NTFS-Rechte-Dschungel einigermaßen
zurecht findet.

Christoph
--
email:
nurfuerspam -> gmx
de -> net
Hans-Peter Matthess
2011-09-22 11:41:27 UTC
Permalink
Post by Christoph Maercker
Post by Hans-Peter Matthess
Post by Christoph Maercker
cd anwend*
cd anwend*
cd anwend*
cd anwend*
Das ist klar, das kann man beliebig treiben, ist auch durch Rechte nicht
untersagt, fragt sich allerdings, warum man sowas Sinnloses tun sollte.
Diverse Datei-Suchprogramme scheinen es zu tun(, weil sie die Junctions
rekursiv sehen). Ohne die hätte ich den Bug gar nicht bemerkt.
Gelegentlich teste ich mal einen x-beliebigen Packer.
Das ist so ähnlich wie mit den "diversen Dateimanagern". Ich hab immer
noch keinen gefunden, der da Mist baut. Es ist z.B. der Name "TC" gefallen,
der macht sowas hier aber nachvollziehbar nicht, sondern verhält sich korrekt.
Gibt es ein bestimmtes Suchprogramm, mit dem sich das nachvollziehen lässt?
Es kann jedenfalls kein Programm eine gesetzte Verweigerung ignorieren.
Das wäre ein glattes Wunder.
Post by Christoph Maercker
Post by Hans-Peter Matthess
In keinem der Anwend* kann irgendwas angezeigt werden.
Das schon, nur die Junctions werden mit DIR nicht mehr angezeigt, das
stimmt.
Die werden eh nur mit "dir /a" angezeigt.
Post by Christoph Maercker
Post by Hans-Peter Matthess
Post by Christoph Maercker
dir anwend*> dir.txt
Da kommt dann halt immer "Datei nicht gefunden".
Bei verkürzten Verzeichnisnamen ja, nicht aber wenn er vollständig
j:\Users\weston\AppData\Local\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten>dir
anw*
Verzeichnis von
j:\Users\user\AppData\Local\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten
Datei nicht gefunden
j:\Users\weston\AppData\Local\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten>dir
anwendungsdaten
Verzeichnis von
j:\Users\user\AppData\Local\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\anwendungsdaten
22.09.2011 08:53 <DIR> .
22.09.2011 08:53 <DIR> ..
30.06.2011 10:53 <DIR> Adobe
15.09.2011 09:16 <DIR> assembly
15.09.2011 09:16 <DIR> Microsoft
27.05.2011 07:40 <DIR> Microsoft Help
29.06.2011 16:47 <DIR> MiKTeX
04.08.2011 15:47 7.595 Resmon.ResmonCfg
Nö:
C:\Users\hpm\AppData\Local\Anwendungsdaten\anwendungsdaten>dir anwendungsdaten
Verzeichnis von C:\Users\hpm\AppData\Local\Anwendungsdaten\anwendungsdaten\anwendungsdaten
Datei nicht gefunden

Es KANN nicht gehen wegen der gesetzten NTFS-Verweigerung.
Aber: "j:\Users"? Huch? Was ist das denn? "Users" ist immer auf C:
Wenn "Users" nachträglich verschoben wird, ist es eh ein vermurkstes, verbasteltes System
und man muss davon ausgehen, dass da rechtemäßig viel im Argen liegt.
Post by Christoph Maercker
Post by Hans-Peter Matthess
Ich dachte jetzt, du hättest eine Möglichkeit gefunden, auf Systemen mit
korrekten Junctions nachvollziehbar Rekursionen zu erzeugen.
Das obige Spiel mit "cd anwend*" ist zwar sowas, ich kenne aber kein
Programm oder keinen User, der sowas machen würde.
Dann dürften sich Dateisuchen, z.B. mit Total Commander nicht in solchen
Pseudo-Verzeichnisbäumen festfahren.
Tut er hier ja auch nicht. Bei mir ist C:\Users allerdings auch nicht verbastelt.
Das dürfte der Unterschied sein.
Wenn ich in ...appdata\local einen Ordner "Test" erstelle und den TC in C:
suchen lasse, findet er nur "C:\Users\hpm\AppData\Local\Test"
mehr nicht. Ebenso ist es mit allen anderen Junctions auch.
Ausnahme: "All Users". Das ist allerdings keine Junction, sondern ein Symlink
und er hat keine Verweigerung von MS bekommen.
Ein Ordner "Test" wird also dummerweise zwei Mal gefunden:
Einmal in "All Users" und einmal in "Programdata".
Auch deswegen haben die Junctions die Verweigerung, sonst würden
Suchprogramme eine Flut von sinnlosen Treffern liefern.
Post by Christoph Maercker
Anscheindend sehen die bei einem
simplen Directory Scan mehr als DIR, sonst würden sie die rekursiven
Unterverzeichnisse nicht finden.
Siehe oben, der TC verheddert sich da nicht, sofern das System nicht
verbastelt ist.

[...]
Post by Christoph Maercker
Allerdings sind die Berechtigungen von "Programme" etwas anders als bei
"Ordnerinhalt auflisten/Lesen" unter "Spezielle Berechtigungen" wird
verweigert. Ich hatte bei $Anwendungsgeraffel die allgemein zugänglichen
Berechtigungen "Ordnerinhalt auflisten" + "Lesen" verweigert. Worin
besteht der Unterschied??
Da müsste man mal die Ausgabe von icacls sehen.
Post by Christoph Maercker
Post by Hans-Peter Matthess
Post by Christoph Maercker
Als ich auf dem 2008-Server in einem der betr.
Verzeichnisse "DEL /S Anwendungsdaten" eingegeben habe, kam prompt die
Frage, ob auch das gleichnamige Unterverzeichnis gelöscht werden soll.
Ich habe an der Stelle sicherheitshalber mit "n" geantwortet.
Bei korrekter Junction kommt da wieder "nicht gefunden".
Bei diesem System hat sich's durch Löschen per Commander erledigt. Beim
nächsten probiere ich mal, ob die "speziellen" den entscheidenden
Unterschied ausmachen.
BTW: Wieviele Admins blicken bei den NTFS-Rechten einklich durch? Wenn
ich das mit den schlappen 7+1 Rechten unter NetWare oder gar den 3x3
Rechten unter Linux/Unix vergleiche ... weil es doch immer heißt,
Windows wäre so einfach zu bedienen ...
Die Frage, ob auch User die NTFS-Rechte beherrschen, erübrigt sich schon
beinahe.
Jeder, der einen Rechner hat, ist ja Admin. Also kennen sich 99,9Periode%
da nicht aus. Ich bin auch weit davon entfernt, das ohne Zuhilfenahme
von Dokumentation alles im Kopf zu haben. :o)
--
Scheinsicherheit und System-Zerstörung durch Virenscanner:
http://www.soehnitz.de/itsicherheit/virenscannersinnoderunsinn/index.html
Darum: http://www.soehnitz.de/itsicherheit/wassiewirklichbrauchen/index.html
Konfiguration einfach gemacht: http://home.arcor.de/skanthak/safer.html
Christoph Maercker
2011-09-22 14:46:45 UTC
Permalink
Post by Hans-Peter Matthess
Das ist so ähnlich wie mit den "diversen Dateimanagern". Ich hab immer
noch keinen gefunden, der da Mist baut. Es ist z.B. der Name "TC" gefallen,
der macht sowas hier aber nachvollziehbar nicht, sondern verhält sich korrekt.
Auf manchen Systemen hier dito.
Post by Hans-Peter Matthess
Gibt es ein bestimmtes Suchprogramm, mit dem sich das nachvollziehen lässt?
TC ALT-F7. Bei *Deinem* System natürlich nicht. Du wirst Dir schon die
Mühe machen müssen, mal eins der zahlreichen vermurksten(?) System zu
testen, wenn Du es unbedingt nachvollziehen willst.
Post by Hans-Peter Matthess
Es kann jedenfalls kein Programm eine gesetzte Verweigerung ignorieren.
Das wäre ein glattes Wunder.
Die Rechte stehen drin, interessiert die genannten Progs nicht die Bohne.
Post by Hans-Peter Matthess
Die werden eh nur mit "dir /a" angezeigt.
Also auch etwas tiefer im rekursiven Verzeichnisdschungel?
Post by Hans-Peter Matthess
C:\Users\hpm\AppData\Local\Anwendungsdaten\anwendungsdaten>dir anwendungsdaten
Verzeichnis von C:\Users\hpm\AppData\Local\Anwendungsdaten\anwendungsdaten\anwendungsdaten
Datei nicht gefunden
Es KANN nicht gehen wegen der gesetzten NTFS-Verweigerung.
Genau das ist die Frage.
Keine Panik: ich hatte zufällig ein Win7-System als Netzlaufwerk gemappt
und habe das als Versuchskarnickel verwendet. Lokal verhalten sich die
betr. Systeme exakt gleich.
Post by Hans-Peter Matthess
Tut er hier ja auch nicht. Bei mir ist C:\Users allerdings auch nicht verbastelt.
Das dürfte der Unterschied sein.
Nein. Die Kiste, deren Netzlaufwerk ich angezapft habe, ist eines
unserer Standartimages. Und nein, nicht nur die haben den Fehler,
sondern auch Systeme, die von völlig anderen Firmen/Leuten installiert
wurden. Hierzugroups scheint es etliche weitere zu geben.
Post by Hans-Peter Matthess
suchen lasse, findet er nur "C:\Users\hpm\AppData\Local\Test"
mehr nicht. Ebenso ist es mit allen anderen Junctions auch.
Ein einziges Mal habe ich das bei einem vorher vermurksten System so
hinbekommen, auf meinem Home-PC und ich hoffe, es bleibt dort so. ALT-F7
ist für mich die schnellste Prüfmethode, ob der Mist komplett weg ist.
Post by Hans-Peter Matthess
Post by Christoph Maercker
Allerdings sind die Berechtigungen von "Programme" etwas anders als bei
"Ordnerinhalt auflisten/Lesen" unter "Spezielle Berechtigungen" wird
verweigert. Ich hatte bei $Anwendungsgeraffel die allgemein zugänglichen
Berechtigungen "Ordnerinhalt auflisten" + "Lesen" verweigert. Worin
besteht der Unterschied??
Da müsste man mal die Ausgabe von icacls sehen.
OK:
C:\>icacls \users\user\* /T
C:\users\user\Anwendungsdaten Jeder:(DENY)(S,RD)
NT-AUTORITŽT\SYSTEM:(I)(OI)(CI)(F)
VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
IMED\user:(I)(OI)(CI)(F)

C:\users\user\Anwendungsdaten\*: Zugriff verweigert

C:\>icacls \users\user\AppData\Local\* /T
C:\users\user\AppData NT-AUTORITŽT\SYSTEM:(I)(OI)(CI)(F)
VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
IMED\user:(I)(OI)(CI)(F)

C:\users\user\Application Data NT-AUTORITŽT\SYSTEM:(I)(OI)(CI)(F)
VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
IMED\user:(I)(OI)(CI)(F)

C:\users\user\AppData\Local\Anwendungsdaten Jeder:(DENY)(S,RD)
NT-AUTORITŽT\SYSTEM:(I)(OI)(CI)(F)

VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
IMED\user:(I)(OI)(CI)(F)

C:\users\user\AppData\Local\Anwendungsdaten\*: Zugriff verweigert>

Preisfrage: Treten bei diesem System Rekursionen auf oder nicht?
--
CU Christoph Maercker.
Hans-Peter Matthess
2011-09-23 10:31:14 UTC
Permalink
Post by Christoph Maercker
Post by Hans-Peter Matthess
Gibt es ein bestimmtes Suchprogramm, mit dem sich das nachvollziehen lässt?
TC ALT-F7. Bei *Deinem* System natürlich nicht. Du wirst Dir schon die
Mühe machen müssen, mal eins der zahlreichen vermurksten(?) System zu
testen, wenn Du es unbedingt nachvollziehen willst.
Wozu? Dass es mit vermurksten Junctions Probleme gibt, ist ja eh klar.
Ich kann solche Rekursionen leicht erzeugen, wenn ich die Rechte verändere.
Mit geht's nur um Probleme mit korrekt funktionierenden Junctions.
Also sowas z.B.:
http://blog.magerquark.de/request-for-help-robocopy-dummfug-unter-windows-vista/
http://www.borncity.com/blog/2009/12/14/pfadlangenlimit-uberschritten-dateisystemobjekte-scheinbar-nicht-mehr-loschbar/
Post by Christoph Maercker
Post by Hans-Peter Matthess
Es KANN nicht gehen wegen der gesetzten NTFS-Verweigerung.
Genau das ist die Frage.
Nö, das ist keine Frage. Kein Programm kann Rechte übergehen. Wenn das
scheinbar doch der Fall ist, hat man beim Setzen der Rechte etwas übersehen
und falsch gemacht.
Post by Christoph Maercker
Keine Panik: ich hatte zufällig ein Win7-System als Netzlaufwerk gemappt
und habe das als Versuchskarnickel verwendet. Lokal verhalten sich die
betr. Systeme exakt gleich.
So kann man eh nicht richtig testen. Die Junction, die eigentlich auf einen
Pfad im anderen System zeigt, zeigt dann ja nun auf das lokale System...
Post by Christoph Maercker
Post by Hans-Peter Matthess
Post by Christoph Maercker
Allerdings sind die Berechtigungen von "Programme" etwas anders als bei
"Ordnerinhalt auflisten/Lesen" unter "Spezielle Berechtigungen" wird
verweigert. Ich hatte bei $Anwendungsgeraffel die allgemein zugänglichen
Berechtigungen "Ordnerinhalt auflisten" + "Lesen" verweigert. Worin
besteht der Unterschied??
Da müsste man mal die Ausgabe von icacls sehen.
C:\>icacls \users\user\* /T
C:\users\user\Anwendungsdaten Jeder:(DENY)(S,RD)
NT-AUTORITŽT\SYSTEM:(I)(OI)(CI)(F)
VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
IMED\user:(I)(OI)(CI)(F)
Sieht gut aus.
Post by Christoph Maercker
C:\users\user\Anwendungsdaten\*: Zugriff verweigert
Kapott. Evtl. mal icacls in einer Konsole ausführen, die Systemrechte hat.
Post by Christoph Maercker
C:\users\user\Application Data NT-AUTORITŽT\SYSTEM:(I)(OI)(CI)(F)
VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
IMED\user:(I)(OI)(CI)(F)
Kapott. Die Verweigerung fehlt.
Post by Christoph Maercker
C:\users\user\AppData\Local\Anwendungsdaten Jeder:(DENY)(S,RD)
NT-AUTORITŽT\SYSTEM:(I)(OI)(CI)(F)
VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
IMED\user:(I)(OI)(CI)(F)
Das sieht wieder gut aus.
Post by Christoph Maercker
C:\users\user\AppData\Local\Anwendungsdaten\*: Zugriff verweigert>
Ziemlich vermurkst.
Post by Christoph Maercker
Preisfrage: Treten bei diesem System Rekursionen auf oder nicht?
Bei solch einem vermurksten Bild würde ich alle Junctions löschen.
Jetzt wüsste ich nur noch gerne, wie man sowas zustande bringt. ;-)
--
Scheinsicherheit und System-Zerstörung durch Virenscanner:
http://www.soehnitz.de/itsicherheit/virenscannersinnoderunsinn/index.html
Darum: http://www.soehnitz.de/itsicherheit/wassiewirklichbrauchen/index.html
Konfiguration einfach gemacht: http://home.arcor.de/skanthak/safer.html
Christoph Maercker
2011-09-23 14:48:21 UTC
Permalink
Post by Hans-Peter Matthess
Nö, das ist keine Frage. Kein Programm kann Rechte übergehen. Wenn das
scheinbar doch der Fall ist, hat man beim Setzen der Rechte etwas übersehen
und falsch gemacht.
So kann man eh nicht richtig testen. Die Junction, die eigentlich auf einen
Pfad im anderen System zeigt, zeigt dann ja nun auf das lokale System...
Lokal funktioniert's aber exakt genauso.
Post by Hans-Peter Matthess
Post by Christoph Maercker
C:\>icacls \users\user\* /T
C:\users\user\Anwendungsdaten Jeder:(DENY)(S,RD)
NT-AUTORITŽT\SYSTEM:(I)(OI)(CI)(F)
VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
IMED\user:(I)(OI)(CI)(F)
Sieht gut aus.
Post by Christoph Maercker
C:\users\user\Anwendungsdaten\*: Zugriff verweigert
Kapott. Evtl. mal icacls in einer Konsole ausführen, die Systemrechte hat.
Post by Christoph Maercker
C:\users\user\Application Data NT-AUTORITŽT\SYSTEM:(I)(OI)(CI)(F)
VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
IMED\user:(I)(OI)(CI)(F)
Kapott. Die Verweigerung fehlt.
Hat aber mit den Rekursionen nichts zu tun, da Parallelverzeichnis.
Post by Hans-Peter Matthess
Post by Christoph Maercker
C:\users\user\AppData\Local\Anwendungsdaten Jeder:(DENY)(S,RD)
NT-AUTORITŽT\SYSTEM:(I)(OI)(CI)(F)
VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
IMED\user:(I)(OI)(CI)(F)
Das sieht wieder gut aus.
Post by Christoph Maercker
C:\users\user\AppData\Local\Anwendungsdaten\*: Zugriff verweigert>
Ziemlich vermurkst.
Post by Christoph Maercker
Preisfrage: Treten bei diesem System Rekursionen auf oder nicht?
Antwort: Es gibt welche, obwohl die Rechte auf "Anwendungsdaten" korrekt
gesetzt sind.
Post by Hans-Peter Matthess
Bei solch einem vermurksten Bild würde ich alle Junctions löschen.
Bei einigen Systemen bereits passiert.
Post by Hans-Peter Matthess
Jetzt wüsste ich nur noch gerne, wie man sowas zustande bringt. ;-)
*Diese* Frage sollte M$ beantworten, wenn hierzugroups schon niemand die
Antwort kennt. Nachdem ich das Problem auf drei grundverschiedenen
Windows-Systemen gesehen habe, fällt der Verdacht sowieso auf dero
Wind...Installer.
--
CU Christoph Maercker.
Helmut Rohrbeck
2011-09-23 15:21:23 UTC
Permalink
Post by Christoph Maercker
Post by Hans-Peter Matthess
Jetzt wüsste ich nur noch gerne, wie man sowas zustande bringt. ;-)
*Diese* Frage sollte M$ beantworten, wenn hierzugroups schon niemand
die Antwort kennt. Nachdem ich das Problem auf drei grundverschiedenen
Windows-Systemen gesehen habe, fällt der Verdacht sowieso auf dero
Wind...Installer.
Dann solltest Du einfach mal bei "M$" fragen:
http://answers.microsoft.com/de-de/windows/forum/windows_7
--
Helmut Rohrbeck
http://www.helmrohr.de/Kontakt.htm
Microsoft Support Center:
http://support.microsoft.com/?ln=de
Christoph Maercker
2011-09-26 07:53:15 UTC
Permalink
Post by Helmut Rohrbeck
http://answers.microsoft.com/de-de/windows/forum/windows_7
Danke, ich bin in MS-Foren eher nicht "zu Hause, deshalb frage ich dort
zunächst, ob schon danach gefragt wurde. ;-) Angesichts der vielen User,
die offenbar das gleiche Problem haben, wurde die Frage wahrscheinlich
längst gestellt.
Auf meinem Home-PC sind die Rekursionen übrigens weg, nachdem ich die
Rechte verweigert habe und zwar nicht "spezielle", sondern einfach
"Ordnerinhalt auflisten" und Lesen. Bei dem W2008-Server, wegen dem ich
den Thread aufgemacht habe, hat hingegen nur Löschen der Junctions
geholfen. Warum, weiß der Geier.
--
CU Christoph Maercker.
Hans-Peter Matthess
2011-09-28 09:36:31 UTC
Permalink
Post by Christoph Maercker
Post by Hans-Peter Matthess
Jetzt wüsste ich nur noch gerne, wie man sowas zustande bringt. ;-)
*Diese* Frage sollte M$ beantworten, wenn hierzugroups schon niemand die
Antwort kennt. Nachdem ich das Problem auf drei grundverschiedenen
Windows-Systemen gesehen habe, fällt der Verdacht sowieso auf dero
Wind...Installer.
Nö, bei einem sauber installierten System gibt's keine Rekursionen
und auch der Windows-Installer erzeugt keine. Insofern kann MS da
nichts beantworten.
--
Scheinsicherheit und System-Zerstörung durch Virenscanner:
http://www.soehnitz.de/itsicherheit/virenscannersinnoderunsinn/index.html
Darum: http://www.soehnitz.de/itsicherheit/wassiewirklichbrauchen/index.html
Konfiguration einfach gemacht: http://home.arcor.de/skanthak/safer.html
Christoph Schmees
2011-09-20 15:01:44 UTC
Permalink
Post by Christoph Maercker
...
Datenträger in Laufwerk C: ist xxx
Verzeichnis von c:\Users\All
Users\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\ ...
29.04.2011 14:54 <DIR> Adobe
06.04.2011 14:42 <DIR> Windows Genuine Advantage
Genauso sieht es momentan auf dem W2008-Server aus, trotz korrekt
gesetzter Rechte. Und es sind wie Du siehst nicht nur
Fremdprogramme, sondern auch M$-eigene, die solche Rekursionen
produzieren.
Post by Hans-Peter Matthess
Ein Klick auf "Löschen" tut's auch.
Im Explorer, wohlgemerkt. Andere Filemanager verrecken an den
Rekursionen.
...
mir ging es genau andersherum: Ich habe schon mehrere
Vista-Rechner hier gehabt, weil sie herummuckelten - u.a. wegen
dieser Rekursionen, wie sich dann herausstellte. Und der
hauseigene Explorer verschluckte sich entweder selbst oder konnte
sie nicht handhaben. Ich konnte das mit einem fremden Commander
lösen.

Christoph
--
email:
nurfuerspam -> gmx
de -> net
Christoph Maercker
2011-09-20 16:06:16 UTC
Permalink
mir ging es genau andersherum: Ich habe schon mehrere Vista-Rechner hier
gehabt, weil sie herummuckelten - u.a. wegen dieser Rekursionen, wie
sich dann herausstellte. Und der hauseigene Explorer verschluckte sich
entweder selbst oder konnte sie nicht handhaben. Ich konnte das mit
einem fremden Commander lösen.
Könnte gut sein, der Mista-Explorer kommt mit den Junctions auch noch
nicht klar und M$ hat mit Win7 wenigstens die Darstellung gefixt.
--
CU Christoph Maercker.
Hans-Peter Matthess
2011-09-20 23:43:17 UTC
Permalink
Post by Christoph Schmees
Post by Christoph Maercker
Im Explorer, wohlgemerkt. Andere Filemanager verrecken an den
Rekursionen.
mir ging es genau andersherum: Ich habe schon mehrere
Vista-Rechner hier gehabt, weil sie herummuckelten - u.a. wegen
dieser Rekursionen, wie sich dann herausstellte. Und der
hauseigene Explorer verschluckte sich entweder selbst oder konnte
sie nicht handhaben. Ich konnte das mit einem fremden Commander
lösen.
Wenn die Leute unsachgemäß daran rumbasteln, ist das kein Wunder.
Die sollen die Pfoten davon lassen, dann verschluckt sich auch niemand.
--
Scheinsicherheit und System-Zerstörung durch Virenscanner:
http://www.soehnitz.de/itsicherheit/virenscannersinnoderunsinn/index.html
Darum: http://www.soehnitz.de/itsicherheit/wassiewirklichbrauchen/index.html
Konfiguration einfach gemacht: http://home.arcor.de/skanthak/safer.html
Christoph Maercker
2011-09-16 14:08:31 UTC
Permalink
Post by Christoph Maercker
... diesmal unter Win2008R2.
Eingestellt sind für das Verzeichnis "Anwendungsdaten" Lesen und "Ordnerinhalte anzeigen" auf Verweigern für Jeder,
Pfad ist \Users\<username>\AppData\Local\Anwendungsdaten\...
Es ist noch verrückter als ich dachte:
1. Jeder wird Read+FileScan verweigert: klappt
2. Die Rekursionen hören scheinbar auf
3. Wechsel in beliebiges anderes Verzeichnis
4. CD $ursprungsverzeichnis: Rekursionen sind wieder da!
5. Überprüfung Berechtigungen: Anzeige wird verweigert!!
6. Besitzübernahme durch Administratoren: klappt
7. Anzeige Berechtigungen: klappt, RS stehr für Jeder auf Verweigern

Warum 5. passiert ist klar, aber wieso man mit beliebigen Programmen
außer Explorer in die nunmehr angeblich gesperrten Verzeichnisse weiter
rekursiv öffnen kann, ist das Rätsel.
--
CU Christoph Maercker.
Loading...