• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

SCSI Scanner und Nutzerrechte [gelöst mit 10.2]

A

Anonymous

Gast
Guten Morgen,

meinen SCSI Scanner funktioniert als Root einwandfrei.

Eingeloogt als User wird der Scanner nicht gefunden.

Wo kann ich dem User Scanrechte erteilen?

Bei SCSI soll es ja unproblematisch sein, einen Thread SCSI Scanner Usrerrechte habe ich nicht gefunden.

Vielen Dank für eure Hilfe.

Beste Grüße

Zydas
 
Das funktioniert ganz genauso wie bei jedem anderen scanner auch. Die User die Scannen können sollen, kommen in eine Gruppe zB Scanner und diese Gruppe kriegt dann Zugriff auf das Device an dem der Scanner hängt.
 
OP
A

Anonymous

Gast
danke für deine Anteilnahme, Ich dachte schon hier ist gar keiner.


Folgenden Thread habe ich gelsen:

http://www.linux-club.de/ftopic67303.html


Dort steht:

Code:
SCSI-Geräte
--------------

Hab ich keine Ahnung von, sollte aber inzwischen automagisch
funktionieren.


und weiter:

Code:
.. wäre ja schön, wenn die Berechtigung eingerichtet würde, aber unter SuSE10.0 wird für meinen neu eingerichteten SCSI-Scanmaker nur root als berechtigt angesehen.

Und ich sehe mit Grimm, daß mein Normaluser nicht scannen darf, dafür erhalte ich beim Start unter root eine zwar schöne, leider aber nicht weiterführende und somit nutzlose Belehrung, wie gefährlich dies sei.


In den vielen anderen von mir gelesenen Threads konnte ich auch keine Lösung finden.

In meiner Yast Nutzerverwaltung finde ich keine Opftion für Scanner oder SCSI-Portzugriff.

Hast Du evtl. einen Link oder weitere Tips für mich?

Danke für deine Hilfe.

Beste Grüße

Zydas
 
Wie ich schon schrieb: Wie bei anderen Anschlüssen auch. Dazu gibt es hier einen Artikel der beschreibt wie man das bei Paralellportscannern macht.
Im Zweifel einfach den User in die Gruppe Scanner einfügen (kuser) und per Konsole als root für das Device /dev/sdXY (je nachdem wie dein Scanner angeschloßen ist) einfach ein
Code:
chown :Scanner /dev/sdXY
ausführen. Evtl. dann noch ein
Code:
chmod 770 /dev/sdXY
hinterher, damit die Gruppe auch wirklich Vollzugriff auf das Device bekommt. Ich empfehle dir aber auf jeden Fall vorher die man-pages zu befragen, vielleicht hab ich dir ja auch gerade beschrieben wie man den Scanner tötet :mrgreen:
 
OP
A

Anonymous

Gast
aus folgendem Thread werde ich versuchen die benötigten Informationen zu entnehmen:

http://www.linux-club.de/ftopic67303.html

Code:
1. Der Resourcenmanager

Lege unter /etc/resmgr.conf.d eine Datei mit Namen
51-scanner.conf an und fülle Sie wie folgt:

# Use /usr/sbin/lsusb to create entries like:
# add usb:vendor=0x1a2b,product=0x3c4d scanner
# to grant access to USB scanners:
add usb:vendor=0x04a9,product=0x220d scanner


Wobei natürlich vendor und product angepasst werden müssen.
(siehe Ausgabe von lsusb). Danach wird der resmgr neu
gestartet:

rcresmgr restart


Nun sollte der Scanner auch für einen Benutzer verfügbar sein.

Das werde ich versuchen auf SCSI zu übertragen.

Ist das der richtige Weg?


Beste Grüße

Zydas
 
OP
A

Anonymous

Gast
Um benötigte Informationen zu erhalten folgendes:

Code:
p320:~ # cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: SAMSUNG SP2004C  Rev: VM10
  Type:   Direct-Access                    ANSI SCSI revision: 05
Host: scsi2 Channel: 00 Id: 00 Lun: 00
  Vendor: AGFA     Model: SNAPSCAN 1236    Rev: 1.50
  Type:   Scanner

# Use /usr/sbin/lsusb to create entries like:
# add usb:vendor=0x1a2b,product=0x3c4d scanner
# to grant access to USB scanners:
# naechste Zeile ist nur ein Beispiel für USB
# add usb:vendor=0x04a9,product=0x220d scanner

add scsi:AGFA,Snapscan scanner



Das Scanner wird also einwandfrei erkannt.

Code:
linux101@p320:~> lsscsi
[0:0:0:0]    disk    ATA      SAMSUNG SP2004C  VM10  /dev/sda
[2:0:0:0]    scanner AGFA     SNAPSCAN 1236    1.50  -
linux101@p320:~>

SCSI scheint also keine besonderen Adressen zu haben.

Nun erstelle ich die Datei 51-scanner.conf

Meine Datei sieht so aus:

Code:
# Use /usr/sbin/lsusb to create entries like:
# add usb:vendor=0x1a2b,product=0x3c4d scanner
# to grant access to USB scanners:
# naechste Zeile ist nur ein Beispiel für USB
# add usb:vendor=0x04a9,product=0x220d scanner

add scsi:AGFA,Snapscan scanner

Mein erster Versuch:

Code:
p320:~ # rcresmgr restart
Shutting down resource manager                                       done
Starting resource manager                                            done
  hald already running, registering devices                          done
p320:~ #


Sieht für mich ja schon ganz gut aus.

Das Aussehen scheint aber zu täuschen. Kooka läßt sich starten, der Scanner wird aber nicht erkannt.

Wenn ich als Root Kooka aus der Konsole starte folgendes Ergebnis:

Code:
p320:~ # kooka
kbuildsycoca running...
libkscan: WARNING: Trying to copy a not healthy option (no name nor desc)
libkscan: WARNING: Trying to copy a not healthy option (no name nor desc)

Vorhergehende Meldung habe ich in der Konsole erhalten.
Kooka ist aber als Root funktionsfähig.


Kann mir jemand sagen was ich ändern muß?

Danke für eure Hilfe.

Schöne Grüße

Zydas
 
OP
A

Anonymous

Gast
http://de.opensuse.org/SDB:Scanner_einrichten_ab_SUSE_LINUX_9.2


Code:
 libusb + resmgr + PAM

Beachten Sie, dass sich die Einzelheiten von Version zu Version ändern. Außerdem wird es zukünftige Erweiterungen geben (z.B. "udev", "HAL", ...). Ein Artikel bzgl. "Scanner einrichten" kann nicht alle Details von USB, hotplug, udev, HAL, resmgr, PAM usw. beschreiben. Konsultieren Sie die entsprechende spezifische Dokumentation, wenn es in einem dieser Bereiche Probleme gibt.

Ein Backend greift via libusb auf einen USB-Scanner zu. Das erfolgt via /proc/bus/usb/xxx/yyy (oder via /sys/bus/usb/devices/) wobei xxx (Bus-Nummer) und yyy (Geräte-Nummer) nicht vorher festgelegt sind. Es wird beim Zugriff via libusb (seit Kernel 2.6) keine feste Gerätedatei (wie etwa /dev/usbscanner beim 2.4 Kernel) verwendet, sondern bei jedem Booten werden die Einträge unter /proc/bus/usb/ neu erzeugt. Daher können Zugriffsberechtigungen nicht mehr dauerhaft mit "chmod" festgelegt werden.

Die Zugriffsberechtigung prüft libusb via resmgr (libusb ist gegen libresmgr gelinkt, siehe "ldd /usr/lib/libusb.so").

Welche Benutzer berechtigt sind, auf welche USB-Geräte zuzugreifen, ist in /etc/resmgr.conf festgelegt:

 class desktop
 ...

 # By default, grant access to all USB devices
 # except for HID and hub devices
 exclude usb:class=3  desktop
 exclude usb:class=9  desktop
 add     usb:any      desktop

 # This rule grants access to users logged in locally
 allow desktop  tty=/dev/tty[1-9]* || tty=tty[1-9]* || tty=:0
 

Alle USB-Geräte werden zur resmgr-Klasse "desktop" hinzugefügt, ausser Geräten der USB-Geräteklassen

    * 3: HID (Human Interface Devices), also Tastaturen und Mäuse
    * 9: Hubs 

Der Zugriff auf die Geräte in der resmgr-Klasse "desktop" wird erlaubt, wenn sich der Benutzer wie folgt angemeldet hat:

    * Via Textconsole (tty=...tty[1-9]*)
    * Via graphischem Login mit XDM oder KDM (tty=:0 - d.h. nur für die erste X Session) 

Der resmgr wird beim Anmelden via Textconsole oder XDM/KDM von einem PAM-Modul aufgerufen und über jede neue Anmeldung eines Benutzers informiert. Das ist in folgenden PAM-Konfigurationsdateien festgelegt:

    * Standardmäßig für Login via Textconsole in /etc/pam.d/login
    * Standardmäßig für Login via XDM/KDM in /etc/pam.d/xdm und /etc/pam.d/xdm-np
    * Optional für Login via ssh in /etc/pam.d/sshd 

Damit wird erreicht, dass standardmäßig nur lokal angemeldete Benutzer Zugriff haben.

So recht verstanden habe ich es aber nicht. Besonders die Übertragung für SCSI Geräte fällt mir schwer.
 
Moin :!:

Eins vorab:
Sollte auf Deine Anfrage mal zwei Stunden keiner Antworten, dann
kann das unterschiedliche Gründe haben. Auf jeden Fall gibt es
kein Anrecht in diesem Forum auf garantierte Antwortzeiten.

Zum Thema:
Wie ich bereits geschrieben habe, habe ich keine Ahnung mit
SCSI Geräten, zumal ich keines zur Hand habe zum Testen.
Ich gehe aber davon aus, dass es nicht unbedingt funktionieren
wird die USB-Sachen auf SCSI zu übertragen.

Mit dem Resourcemanager hat es mit Sicherheit auch zu tun,
da SANE dieses Teil unterstützt. Wichtig ist es aber herauszufinden
welche Datei zur Kommunikation verwendet wird - und diese Datei
ist dann mit geeigneten Zugriffsrechten zu versehen, dann sollte
das klappen. Es gab, wenn ich mich richtig erinnere mal einen
Device-Node, /dev/scanner, der dann einen SCSI-Scanner
dereferenzierte, letztendlich war das aber ein Link nach /dev/sgX
X=[0..9,a..z], also ein generisches SCSI- Gerät.

Schau Dir mal man sane-scsi an evtl gibt es da weitere Hinweise.

Viel Erfolg
Gerhard
 

TomcatMJ

Guru
Hi!
Da SCSI-Geräte ja eigentlich nicht im betrieb ein und ausgestöpselt werden (im Normafall zumindest) dürften die Device-Nodes nötigenfalls über die /etc/permission Dateien in ihren Zugriffsrechten Modifiziert werden. Deshalb würde ich an deiner Stelle einfach mal gucken ob dein System dort eventuell falsche Rechte für das Device eingetragen hat und das sonst einfach korrigieren. Wenn dort das Deice noch gar icht drinsteht, kannst du es auch einfach nach dem in den dateien zu genüge vorhandenen Muster ja dort einstellen. Ich würde zu 0660 als Rechtemaske Tendieren und als Gruppe users wählen damit alle ordentlich am System angemeldeten Benutzer den Scanner nutzen können. Mit meinem Mustek 600 II CD (auch ein SCSI-Scanner übrigens) war das nicht nötig, da das Device /dev/sg1 dort schon richtig eingestellt war,allerdings nutze ich auch nicht die Einstellung des Securitylevels paranoid oder secure, wo durchaus eine Einschränkung auf das Device gemacht sein kann, sondern easy.

Bis denne,
Tom
 
OP
A

Anonymous

Gast
ich bin immer so aufgeregt wenn etwas nicht funktioniert.

So viele haben meine Thread gelesen, jedoch keiner wußte etwas.

Ich btte um Entschuldigung.

Schöne Grüße

Zydas
 
OP
A

Anonymous

Gast
Guten Tag,

also mein Scanner funktioniert mit Kooka, wenn ich als root eingeloggt bin einwandfrei.

Dann wird die Fehlfunktion als User doch nicht mit sane-scsi zusammenhängen oder liege ich das falsch?

Unter SuSE 9.2 und SuSE 9.3 konnten die User auch scannen.

Wie kann ich das folgende Securitiyleyer ändern/abschalten:

Einstellung des Securitylevels paranoid oder secure, wo durchaus eine Einschränkung auf das Device gemacht sein kann, sondern easy.


Habt Ihr weitere Ideen?

Schöne Grüße

Zydas[/code]
 
Moin,

jetzt muss ich Dich halt nochmals rügen :!:
Versuch doch mal die Hinweise umzusetzen und mach einen
Schritt nach dem anderen:
1. Scannen als Dummuser --> Rechte für /dev/sgX ändern
2. Einstellungen über die Rebootphase retten

sane-scsi war gedacht als Hinweis, um weiter zukommen, um zu
verstehen, wo das Problem liegen könnte. Der SANE SCSI
Wrapper nutzt zum Beispiel den Resourcenmanager, also sollte
man schon verstehen, wie, wo, was anzupassen ist.

TomcatMJ hat Dir auch wertvolle Hinweise gegeben, also was willst
Du mehr.

Die Sicherheitseinstellungen für das System kannst Du via YAST
ändern: YAST-Kontrollzentrum aufrufen, Rubrik "Sicherheit und
Benutzer", dort "Einstellungen zur Sicherheit", Benutzerdefinierte
Einstellungen und durchklicken...

HTH
Gerhard
 
OP
A

Anonymous

Gast
http://www.multimedia4linux.de/coolscan/coolscan-suse.html


Installieren
ACHTUNG:
Alle Änderungen auf eigene Gefahr. Ich bin mir nicht sicher, ob Sie mit dieser Änderung keine Sicherheitsloch aufmachen!

Falls noch nicht geschehen installieren Sie bitte die SCSI-Karte und schliessen den Scanner an. Bei SuSE 10.0 sollte die SCSI-Karte automatisch erkannt und installiert werden. Bitte installieren Sie über Yast nach das Packet sane. Als grafisches Frontend zum Scannen von Dia empfehle ich ihnen xsane zu installieren.

Zum Scanner benötigen Sie auf das Gerät Schreibzugriff. Nach der Installation haben Sie noch keine Schreibrechte, daher läst sich z.B. xsane nur mit dem root user starten.

klemmh@klemm-hamburg:~> ls -l /dev/sg*
crw-r----- 1 root disk 21, 0 2006-05-09 17:18 /dev/sg0
crw-r----- 1 root disk 21, 1 2006-05-09 17:18 /dev/sg1
crw-r----- 1 root disk 21, 2 2006-05-09 17:18 /dev/sg2
crw-r----- 1 root disk 21, 3 2006-05-09 17:18 /dev/sg3
crw-r----- 1 root disk 21, 4 2006-05-09 17:18 /dev/sg4
crw-r----- 1 root disk 21, 5 2006-05-09 17:18 /dev/sg5
klemmh@klemm-hamburg:~>

Um Schreibzugriffe auf die Gruppe disk zu bekommen starten Sie das Yast Modul Benutzer bearbeiten und anlegen. Sie müssen jetzt jedem user der Zugriff auf den Scanner bekommen soll die Gruppe disk zuordnen.

Öffnen Sie jetzt mit einem Texteditor mit dem root user die Datei /etc/udev/rules.d/50-udev.rules und suchen folgende Zeile:

KERNEL=="sg*", NAME="%k", GROUP="disk", MODE="600"

Ändern Sie MODE="600" auf MODE="660" um und speichern die Datei ab. Der Scanner läst sich nach einem Neustart mit den freigegeben usern benutzen. Achten Sie darauf, das der Scanner vor dem Booten eingeschaltet ist!



-------------------------------------------------


Hallo guten Tag,

sind bei dieser Lösunge irgendwelche Sicherheitslöcher entstanden?

Ich habe nur dem User die Rechte für Disk zugordnet. Der Scanner funktioniert jetzt auch wenn nur ein User eingegeloggt ist.

Welchen sind hat folgendes:

Code:
Öffnen Sie jetzt mit einem Texteditor mit dem root user die Datei /etc/udev/rules.d/50-udev.rules und suchen folgende Zeile:

KERNEL=="sg*", NAME="%k", GROUP="disk", MODE="600"

Ändern Sie MODE="600" auf MODE="660" um und speichern die Datei ab. Der Scanner läst sich nach einem Neustart mit den freigegeben usern benutzen. Achten Sie darauf, das der Scanner vor dem Booten eingeschaltet ist!

Von mir wurde keine Änderung von mode=600 oder mode=660 vorgenommen.
Der Scanner funktioniert.

Als Kernel verwende ich:


Code:
p320:~ # cat /proc/version
Linux version 2.6.16.21-0.25-smp (geeko@buildhost) (gcc version 4.1.0 (SUSE Linux)) #1 SMP Tue Sep 19 07:26:15 UTC 2006
p320:~ #


Warum die Änderung von 600 zu 660?


Schöne Grüße

Zydas
 
Zydas schrieb:
Warum die Änderung von 600 zu 660?


Schöne Grüße

Zydas
Du solltest dich wirklich mal ernsthaft mit der Rechtevergabe unter Linux beschäftigen! 600 bedeutet das nur der User, dem die Datei gehört, lesen und schreiben darf, während 660 bedeutet das der User und die Gruppe lesen und schreiben darf.
Eigne dir in deinem eigenen Interesse die Grundlagen an!
 
OP
A

Anonymous

Gast
Guten Morgen Geier,

sicherlich hast Du recht mit der Rechtevergabe. Ich beschäftige mich gerade gezwungenermaßen mit der Rechtevergabe bei SuSE Linux 10.1.

Die Problem scheinen aber mehrere zu haben.

Welche Sicherheitlöcher habe ich durch die Freigabe der Disk für die User geöffnet?

Schöne Grüße

Zydas
 
Moin,

ich finde es ja löblich, dass Du Dich um die Lösung Deines
Problems bemühst. Die meisten Leute hier wissen aber
sehr wohl, was chmod, chown etc. machen, bzw. was 660, 600
oder gar 400 zu bedeuten hat. Lediglich das wo und wie
ist immer mal wieder geändert worden.

Du solltest auch mal wirklich versuchen auf die Antworten
einzugehen, die Dir gegeben worden sind und nicht bei jedem
Post einen weiteren Brocken hinzuschmeißen. Abgesehen davon
solltest du Abstand davor nehmen Inhalte fremder Pages einfach
so zu kopieren - Copyright und so:?::!:

Nachdem Dein Problem jetzt gelöst ist, werd ich mal den Thread
als solved markieren.

Ach ja, ein Sicherheitsloch wird nicht aufgerissen, es sei denn
Du weißt nicht was Du tust, wenn Du nun der Gruppe Disk angehörst ;)

Gerhard
 

TomcatMJ

Guru
TomcatMJ schrieb:
Hi!
Da SCSI-Geräte ja eigentlich nicht im betrieb ein und ausgestöpselt werden (im Normafall zumindest) dürften die Device-Nodes nötigenfalls über die /etc/permission Dateien in ihren Zugriffsrechten Modifiziert werden. Deshalb würde ich an deiner Stelle einfach mal gucken ob dein System dort eventuell falsche Rechte für das Device eingetragen hat und das sonst einfach korrigieren. Wenn dort das Deice noch gar icht drinsteht, kannst du es auch einfach nach dem in den dateien zu genüge vorhandenen Muster ja dort einstellen. Ich würde zu 0660 als Rechtemaske Tendieren und als Gruppe users wählen damit alle ordentlich am System angemeldeten Benutzer den Scanner nutzen können.

Was gibst daran eigentich falsch zu verstehen? Die Devicerechte direkt in /dev zu ändern ist ziemlicher Schwachsinn,da dies durch Updates später eventuell ungefragt geändert werden könnte, wohingegen Änderungen in den Permissionfiles normalerweise auch nach Updates noch vorhanden sind. Da werden dann die neueren, durch Updates erhaltenen Versionen Aufgrund der eigenhändigen Änderungen vom System eben nicht aktiviert, sondern sollten manuell gecheckt und ggf. angepasst werden. Bist du sicher, daß du die Antworten hier überhaupt lesen willst? Mir kommts jedenfalls nicht so vor als würdest du sie lesen....

Bis denne,
Tom
 
OP
A

Anonymous

Gast
Guten Morgen,

mein in diesem dargestellte Problem wurde mit der Nutzung von
openSUSE 10.2 gelöst.

Der Scanner läßt sich mit 10.2 einwand betreiben.

Also doch irgendwie ein Bug in 10.1.




Beste Grüße

Zydas
 

kohlhz

Member
Also, ich verstehe diese Sorte von Problem auch immer noch nicht.

Mein SCSI-Scanner lief in 10.3 ohne weiteres Zuttun in Usermode, in vorher und in 11.0 + 11.1 wieder nur als root.
Richte ich das jetzt, funktioniert es demnächst wieder nicht, und selbst wenn ich versehentlich noch wüßte, wie es früher zu richten war - es geht fast sicher anders.

Ein Scanner ist ein Gerät, das von den meisten nur hin und wieder benutzt wird - und dann hat es einfach und sofort zu tun.
Zudem soll es so seltsame user wie mich geben, die Linux oder irgendetwas anderes einfach nur als Betriebssystem benutzen wollen, und nicht als ständig zu hegendes und pflegendes Tamagotchi.

Die Unix-Geräte- und Rechteverwaltung ist seit Anbeginn einer der größten Pferdefüße dieses Systems, wie sich auch in der 11.1 wieder zeigt.
Ich habe noch die Zeiten erlebt, als ausgewiesene Experten es als höchste Softwarekunst empfunden haben, mit Ascii-Editor (ed, vi) codierte Binärdateien zur Beschreibung von experimentell erkundeten Bildschirmeigenschaften zu erstellen und diese Technik vehement verteidigt haben, doch ähnlich verschroben kommt mir die heutige Zugriffsrecht-Methodik vor.

Vielleicht hilft ja etwas sanftes Streicheln, um irgendein williges, kundiges und genügend durchsetzungsfähiges Implementiererteam zu finden, der wie weiland Herakles diesen - pardon - Augiasstall ausmistet! (Das wäre allerdings leider etwas, was weit über die Aufgaben einer Linux-Distributors hinausginge ...)

... Sorry, wird nicht wieder vorkommen, keiner der Gurus hier kann an der Situation etwas ändern, nur sein bestes tun, anderen zu helfen, und alle Gurus hier tun das, ohne sich maßlos über das nur zu verständliche Unverständnis uneinsichtiger Nutzer wie mich zu ärgern, was ja auch verständlich wäre, aber manchmal überwältigt einen eben der Zorn ... :-( :irre: :D
 
Oben