Vorsicht vor WinAVR!

Heiko Nocon schrieb:

Warum vermutest Du das?

Christian

Sonst noch ganz Knusper, ja?

Heiko Nocon schrieb:

Wenn Schusseligkeit eine mögliche Erklärung für einen Fehler ist, muß man nicht weiter suchen.

Falk

Heiko Nocon schrieb:

Dann wäre es sinnvoll zu erzählen, wie man das wieder beseitigt.

Bernd

"Falk Willberg" schrieb im Newsbeitrag news: snipped-for-privacy@mid.individual.net...

Wenn man die Erde zum Mittelpunkt der Welt machtm, muss man nicht weiter Erkenntnis sammeln.

-- Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net homepage:

Ja, das würde den Beitrag natürlich erst sinnvoll komplettieren. Danke für diese Anregung. Hätte ich auch allein darauf kommen können, daß das durchaus für einige Leute hilfreich sein könnte.

Also:

Regedit mit Adminrechten starten, zum genannten Schlüssel navigieren. Rechtsklick darauf->Berechtigungen->erweitert. Es sind nur zwei Einträge zu sehen (für System und Administratoren) und diese sind nicht ererbt, sondern für diesen Schlüssel explizit gesetzt.

Wenn das so ist, hat das genannten Problem zugeschlagen und dann (und nur dann!) ist das folgende nötig.

2) Knopp "Übernehmen" anklicken

4) Wir haben fertig.

Heiko Nocon schrieb:

Hast du denn wenigstens einen Bugreport dafür geschrieben?

snipped-for-privacy@uriah.heep.sax.de (Joerg Wunsch):

Denkbar wär ja auch, dass sich jemand Zugriff zum CVS des Projektes verschafft hat und nun nach Gutdünken rumsabotiert. Imho sind die CVS's nur recht schwach gesichert; public-Zugriff sowieso für alle möglich, da reicht nur ne kleine Sicherheitslücke (oder eben das passwd) und Schreibrechte sind nicht weit. Wenn man dann auch noch das System hat, kann man sogar ändern, ohne dass es das CVS mitkriegt. Ich seh schon ne neue Klasse von Schädlingen: bewusst von Hackern eingebaute Bugs (oder Programm-Rümpfe) auf die dann - möglicherweise erst Jahre später - Viren draufgesetzt werden. Auf einmal fehlerfrei laufende hunderttausende Zeilen Quellcode schaut doch später niemand mehr drauf.

M.

Heiko Nocon schrieb:

Hier hat dieser Schlüssel keine Vererbungsrechte, die ACL enthält SYSTEM(F) und JEDER(R). Das System ist noch recht frisch und WinAVR verwenden wir nicht, das scheinen also die Voreinstellungen von MS zu sein.

bye Rudi

Rüdiger Ranft meinte:

Bei mir ebenso, auf der Maschine war noch nie WinAVR, XP 64-Bit.

ACK, bei mir ist das auch so.

Heiko Nocon schrieb:

Hallo,

das Du beim Schreiben dieser Zeilen auch nicht richtig nachgedacht hast beweist der zweite Absatz überdeutlich...

Bye

Man wuenscht also jemand fuer den MS default die toedliche Krankheit an den Hals oder wie jetzt?

Micha

"Heiko Nocon" schrieb

Welche hättest Du gerne?

Siehst Du, geht doch :-)

Da ich gerade erst zu Hause WinAVR installiert habe, werde ich mal gucken, ich hatte gar keine Berechtigungen im regedit finden können. Mit der Registry stehe ich ohnehin auf Kriegsfuß.

Reicht es als Benutzer mit Adminrechten? Bei mir offenbar nicht, habe keine Möglichkeit Berechtigungen zu sehen/ändern. Auch gestartet mit "runas /user:Administrator regedit.exe" geht es nicht, das Kontextmenü bietet an: Ausblenden, Neu, Suchen..., Löschen, Umbenennen, Schlüsselnamen kopieren

Ah, man muß unter Win2000 regedt32 starten, dann gibt es neben gruseliger Vorkriegsoptik auch ein fehlendes Kontextmenü und unter Sicherheit/Berechtigungen kann man das passend einstellen.

Das ist allerdings hier auch auf einem nicht-WinAVR-System bereits so, dort sind gesetzt Lesen für Jeder und Vollzugriff für SYSTEM, das Kästchen für vererbbare ist nicht gesetzt.

Bernd

sein.

:) Bei einigen Defaults ist das sicher schon fast verst=E4ndlich ...

Guido

Ja. Ich war zum Zeitpunkt meines Postings gezwungen, die ursprüngliche Konfiguration zu erraten, da sie ja von WinAVR manipuliert wurde und mir kein sauberes Referenzsystem zur Verfügung stand. Inzwischen konnte ich es mit einer frischen Installation überprüfen und deine Angaben bestätigen. Es wird also nicht die Vererbung gesperrt, sondern "nur" explizit für den Schlüssel gesetzte default-Rechte durch andere ersetzt. Ich sehe allerdings nicht, was daran weniger schlimm sein sollte.

Der springende Punkt ist nach wie vor, daß WinAVR die Leseberechtigung für normale Benutzer entfernt, nach der Installation sieht das nämlich (in deiner Notation) so aus: SYSTEM(F) und Administratoren(F).

Das führt dazu, daß etliche Tools, die in irgendeiner Form mit Ports rummachen, plötzlich nicht mehr oder nicht mehr richtig funktionieren, wenn sie mit Benutzerrechten laufen.

Und ich bin auch immer noch sehr im Zweifel, ob es sich um einen Bug im klassischen Sinne handelt. Ich konnte zwar bisher nichts im Paket finden, was daraus Vorteile ziehen würde, den Benutzer zu zwingen, mit Adminrechten zu arbeiten, aber genausowenig konnte ich etwas finden, für das die Manipulation der Rechte dieses Registryzweiges überhaupt notwendig ist.

Die ganze Sache bleibt also zumindest hochverdächtig. Und bis zu einer stichhaltigen Erklärung, weswegen es nötig ist, diese Rechte zu manipulieren, halte ich also meine Warnung vor WinAVR uneingeschränkt aufrecht.

Matthias Weingart schrieb:

Hast du schon mal geguckt, /was/ so in WinAVR's CVS überhaupt rumliegt?

Jedenfalls nichts, was den Installer betrifft (den Heiko ja hier verdächtigt). Theoretisch könnte wohl jemand einen GCC-Patch manipulieren, aber dazu müsste er sich erstmal eines ssh-Schlüssels eines Entwicklers bemächtigen (und am Ende würde sein Werk vermutlich trotzdem nur ignoriert ;-).