verfaßt von baeuchlein, 19.04.2017, 02:27:44
> > Jedoch kann ich nicht erkennen,
> > wie ein Benutzer die Konfiguration des OS' vermurksen kann, wenn er ein
> > "Read-Only"-Gerät wie den Scanner anspricht.
>
> In dem er, nachdem er die Gerätedatei(en) mehr oder weniger durch Zufall
> gefunden hat,
> neugierig wie er ist, im Editor öffnet.
> Und ann, gewollt oder ungewollt, irgendwas überschreibt und abspeichert.
>
> Schon hat das System keinen Scanner mehr.
>
> Was nicht ganz so tragisch ist, aber stell dir vor, der findet fstab o.ä.
> und überschreibt dort drin Einträge oder löscht die Datei
Meines Wissens ist etwas in /dev was anderes als was in /etc. Was in /etc drin steht, ist meistens dazu gedacht, dass irgendwer (normalerweise ein Admin) es ändern kann, oft mit einem Texteditor. Bei Dateien in /dev habe ich von sowas nie jemals gehört oder gelesen; in seltenen Fällen soll man wohl mal bestimmte Zeichenfolgen da hin kopieren, aber die kann man dann auch nicht gleich wieder aus den Dateien in /dev lesen. Siehe z.B. Dateien wie /dev/zero, /dev/null usw..
Ich halte es daher nicht für sinnvoll, zu editierende Konfigurationsdateien in /etc mit Gerätedateien in /dev zu vergleichen. Ich gehe so weit mit, dass weder in /etc noch in /dev für gewöhnlich jemand anders als ein Admin was zu suchen hat, aber den Rest sehe ich hier anders als du und glaube daher nicht, dass diese Diskussion jetzt noch sinnvolle Ergebnisse liefert. Sowieso wäre das alles ja nicht nötig, wenn der eigentliche "Normalweg" zum Benutzen des Scanners (über die Zugehörigkeit des Benutzers zur Gruppe "scanner") funktionieren würde. Lassen wir's mal gut sein mit den /dev-Dateien.
> > > Auch dafür habe ich es noch nicht gebraucht; mein letzter und mein
> > > aktueller Drucker hingen/hängen direct am Router - nie Probleme
> >
> > Meine Drucker sind halt keine Netzwerkdrucker,
>
> Sag doch gleich, dass du einen USB-Drucker im Netz verwendest...
Das ist eigentlich nicht so relevant, wie du annimmst. Ich komme gleich noch dazu...
> > kiloweise Hardware wegwerfen (wohinter Unmengen bei der Herstellung
> > verbrauchter Ressourcen stehen), nur weil ein paar Leute ihr CUPS nicht
> > anständig programmieren, nicht anständig testen oder aus anderen Gründen
> in
> > nicht funtionierender (und stetig weiter verschlechterter) Form
> ausrotzen.
>
> Das ein USB-Drucker nur auf Umwegen als netzwerkdrucker angesprochen werden
> kann, hat nichts mit "CUPS ist nicht anständig programmiert" zu tun.
Darum geht es hier nicht. Es ist erstens nicht zwingend ein USB-Drucker, sondern es gibt verschiedene lokale Drucker an USB- oder gar LPT-Anschlüssen. Zweitens wird er auch nicht als Netzwerkdrucker angesprochen, sondern CUPS kommuniziert mit dem Betriebssystem des Rechners über das Samba-Protokoll. Ein Unterschied ist dann z.B., dass der Drucker im Gegensatz zu Netzwerkdruckern keine IP-Adresse hat. Auch die IP-Adresse des Rechners, an dem dieser Drucker hängt, ist nicht dem Drucker zugeordnet. Unter Windows würde man von einer Druckerfreigabe reden, unter Linux heißt es meistens "shared printer" oder manchmal auch "samba printer" o.ä..
Das Problem ist hier, dass CUPS das in früheren Versionen einigermaßen hinkriegte, mittlerweile aber überhaupt nicht mehr. Und wenn ich dann die log-Dateien durchwühle, fällt mir z.B. auf, dass CUPS dann an den Rechner mit dem Drucker dran eine Benutzername/Passwort-Kombination schickt, die falsch ist: Benutzer "root", Passwort aber vom "normalen" Benutzeraccount. Kann ja nicht funktionieren. Hab' ich dem CUPS auch nie so eingegeben.
Vorhin habe ich auch mal im Internet nachgesehen. Da wird dem CUPS-Nutzer generell gesagt (also auch wenn es um was ganz anderes bei CUPS geht), wenn CUPS nach Benutzername und Kennwort fragt, dann gib' auf jeden Fall Name und Passwort für den "normalen" Benutzeraccount an, nicht die für "root". Nur dass das in meinem Fall nicht stimmt; fragt bei mir CUPS nach Name und Kennwort, dann muss es grundsätzlich eben doch die Kombination für "root" sein (was auch Sinn ergibt, ich werde nur bei Aufgaben gefragt, wo mal Admin-Rechte nöitg sind). Schon die "Anleitung", wenn man das so nennen will, stimmt hier also nicht.
Und so geht das unter CUPS schon seit Jahren, wenn es um Berechtigungen (Zugriffsrechte usw.) geht. Das liegt nicht am Benutzer oder der Technik, da haben die Hersteller, Programmierer oder was auch immer von CUPS Fehler gemacht. Diese treten fast ausschließlich beim Drucken auf einen per Samba freigegebenen Drucker im Netzwerk auf. (Und sowieso ist die CUPS-Dokumentation bei solchen Samba-Druckern völlig unbrauchbar, weil da nahezu gar nichts drin steht - nicht mal, wie man genau den Drucker in der Eingabemaske angeben soll. Spätestens das gehört da aber hin. Ich hab' den deutlichen Eindruck, die haben keinen Bock auf Drucken über Samba, bei anderen Druckprotokollen geben die sich in der Doku erheblich mehr Mühe.)
Ob es auch bei anderen Protokollen zum Drucken im Netzwerk solchen Ärger mit den Zugriffsrechten gibt, z.B. bei ipp, das weiß ich nicht. Aber dessen Einsatz ist in meinem Fall sowieso völlig sinnlos.
Wenn also CUPS (bzw. seine Dokumentation) behauptet, es könne auf per Samba freigegebene Drucker drucken, dann aber nicht beschreibt, wie der Admin das einstellen soll und außerdem noch erwiesenermaßen Fehler bei der Übergabe der Benutzername/Passwort-Kombination macht, dann haben die CUPS-Entwickler hier gehörig was falsch gemacht, teilweise eben auch nicht korrekt programmiert. Und getestet hat's ganz offensichtlich auch keiner. Dann behaupte man aber gefälligst auch nicht in der Doku, dass das ginge.
> BTW: das hier:
> https://wiki.ubuntuusers.de/Scanner/
> kennst du?
Diese Seite nicht, ich mache ja nix mit Ubuntu. Ich hab's mir jetzt mal grob angesehen; die meisten Dinge dort habe ich aber woanders auch schon so gelesen und ausprobiert, ohne Erfolg. Ich werd' irgendwann mal die paar Vorschläge durchgehen, die ich noch nicht kenne. Jedenfalls danke für den Link, vielleicht klappt ja mal was davon.
gesamter Thread: