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

[gelöst] Einige USB Sticks erfordern zum Einbinden root Rechte unter OpenSuSE 13.2

goeba

Hacker
Hallo, wie hier : http://linux-club.de/forum/viewtopic.php?f=90&t=119700&p=769979#p769985 gewünscht eröffne ich ein eigenes Thema.

Ich habe eine Menge frisch installierter Open SuSE 13.2 Clients.

Bei etwa 90% der verwendeten Sticks funktioniert alles, wie man es erwarten würde: Man meldet sich an, steckt dann seinen Stick rein, der wird automatisch eingebunden und lässt sich mit Dolphin öffnen.

Bei einigen wenigen Sticks passiert folgendes:
- die automatische Einbindung startet nicht
- in Dolphin wird das Gerät als Felstplatte angezeigt
- wenn man auf das Festplattensymbol klickt, wird nach dem Root Kennwort gefragt
- wenn man dieses eingibt, dann ist anschließend der Stick als externe Festplatte eingebunden, während ein "normaler" Stick als "Wechselmedieum" eingebunden ist.

Ich kann meinen Usern aber keine Root Rechte geben, so viel ist klar. Es handelt sich um Rechner in einer Schule, da ist das ein echtes Problem wenn ein Schüler mit seinem Stick kommt, wo das in nächtelanger Arbeit erstellte Referat drauf ist, und dann geht das nicht.

Einen solchen Stick bekam ich heute mal zu fassen, ich habe mit

Code:
udevadm info -a -p $(udevadm info -q path -n /dev/bus/usb/007/002) | less

mal die Daten des Sticks ausgelesen:

Code:
looking at device '/devices/pci0000:00/0000:00:1a.7/usb7/7-1':
KERNEL=="7-1"
SUBSYSTEM=="usb"
DRIVER=="usb"
ATTR{bDeviceSubClass}=="00"
ATTR{bDeviceProtocol}=="00"
ATTR{devpath}=="1"
ATTR{idVendor}=="058f"
ATTR{speed}=="480"
ATTR{bNumInterfaces}==" 1"
ATTR{bConfigurationValue}=="1"
ATTR{bMaxPacketSize0}=="64"
ATTR{busnum}=="7"
ATTR{devnum}=="2"
ATTR{configuration}==""
ATTR{bMaxPower}=="200mA"
ATTR{authorized}=="1"
ATTR{bmAttributes}=="80"
ATTR{bNumConfigurations}=="1"
ATTR{maxchild}=="0"
ATTR{bcdDevice}=="0112"
ATTR{avoid_reset_quirk}=="0"
ATTR{quirks}=="0x0"
ATTR{serial}=="13112800003123"
ATTR{version}==" 2.00"
ATTR{urbnum}=="568"
ATTR{ltm_capable}=="no"
ATTR{removable}=="unknown"
ATTR{idProduct}=="6387"
ATTR{bDeviceClass}=="00"


Ich habe es aber mit verschiedenen Anleitungen (etwa hier: https://wiki.archlinux.org/index.ph...hat_should_be_treated_as_removable.2C_are_not und hier: http://weininger.net/how-to-write-udev-rules-for-usb-devices.html ) nicht hinbekommen, dass der Stick vom normalen User eingebunden werden darf. Außerdem würde mir das vermutlich nur für genau diesen einen Hersteller helfen.

Daher meine Fragen:
- kann man vielleicht einfach die udev-rules von SuSE 13.1 nehmen (wo das offenbar noch kein Problem war, wenn ich die anderen Fäden richtig deute), oder hätte das Nebenwirkungen?
- könnte man in einer der udev-Regeln das Einbinden externer Platten für normale User erlauben, wenn ja, wie? Wie gefährlich wäre das?
- oder gibt es andere, besser gefplegte udev-Regeln, die man statt derer aus SuSE 13.2 nehmen könne, evtl. sogar ein anderes udev-Paket?

Ich bin für jede Hilfe dankbar. Das mag nach einem kleinen Problem klingen, ist es bei meinem Nutzerkreis aber nicht!

Dan und Gruß,

Andreas
 

Sauerland

Ultimate Guru
Was sagt
Code:
fdisk -l
zu dem Stick?

In der Konsole:
Code:
journalctl -f
bzw.
Code:
tail -f /var/log/messages
eingeben, Stick anschließen und die entstehenden Meldungen hier posten.
 
OP
G

goeba

Hacker
Ich komme erst MOntag an einen solchen Stick wieder heran.

Falls vorher noch jemand eine Idee hat, immer her damit, aber vielen Dank schon mal!

Andreas
 

josef-wien

Ultimate Guru
Außerdem als normaler Benutzer die gesamte Ausgabe von
Code:
/sbin/udevadm info -a -p $(/sbin/udevadm info -q path -n /dev/sdXY)
udisksctl mount --block-device /dev/sdXY
(XY mußt Du bei beiden Befehlen anpassen).

Du kannst einmal als root die Ergebnisse von
Code:
udevadm test -p $(udevadm info -q path -n /dev/bus/usb/007/002)
bzw.
Code:
udevadm test -p $(udevadm info -q path -n /dev/sdXY)
vom "Problem-Stick" und von einem "funktionierenden" vergleichen, aber so recht glaube ich nicht an udev als Problem-Ursache.

Eine theoretische Möglichkeit wäre, daß der Stick aus welchem Grund auch immer als internes Medium betrachtet wird, dann könnte (falls 13.2 nicht anders funktioniert als 13.1) die Eintragung
Code:
org.freedesktop.udisks2.filesystem-mount-system         auth_admin:auth_admin:yes
in /etc/polkit-default-privs.local (samt Ausführung des in der Datei genannten Befehls) helfen, wenn auch mit dem dadurch entstehenden Risiko, daß das auch für wirkliche interne Medien gilt.
 
OP
G

goeba

Hacker
und die Tatsache, dass es in anderen Linux-Distributionen geht (Mint, Ubuntu, X-Ubuntu, Slackware), nur in Open SuSE 13.2 nicht, gibt nicht Anlass, hier an einen grundsätzlichen Bug in Open Suse zu glauben?

Ich schreibe dann Montag die Ergebnisse der oben angefragten Befehle. Das Symptom für einen einzigen Stick zu beheben nützt mir aber nichts. Ich würde gerne das Verhalten anderer Linux-Distributionen auf OpenSuSE 13.2 reproduzieren. Wie gesagt, ich konnte reproduzierbar sehen, dass beide Sticks, die nicht automatisch eingebunden wurden, in KDE als "externes Laufwerk" erschienen, nicht als "Wechselmedium".

An welcher Stelle im System wird denn entschieden, ob ein usb-Datenträger ein "externes Laufwerk" oder ein "Wechselmedium" ist? Ich denke schon, dass das über die udev-rules geht.

Was könnte denn passieren, wenn ich die udev-Rules einer älteren SuSE Version oder eines anderen Linux Systems nehme?
 

josef-wien

Ultimate Guru
goeba schrieb:
Du übersiehst die Tatsache, daß openSUSE als quasi Testplattform für die Enterprise-Versionen eine wesentlich restriktivere Berechtigungsphilosophie als andere Distributionen verfolgt.

goeba schrieb:
das Verhalten anderer Linux-Distributionen
Vergleiche z. B.
Code:
pkaction --action-id org.freedesktop.udisks2.filesystem-mount-system --verbose
(unabhängig davon, ob diese Spur zum Ziel führt).

goeba schrieb:
Was könnte denn passieren, wenn ich die udev-Rules einer älteren SuSE Version oder eines anderen Linux Systems nehme?
Ich bin kein Prophet, zwischen "alles funktioniert" bis "nichts geht mehr" ist alles denkbar.

In die Entscheidung, ob ein Medium als "removeable" gilt oder nicht, läßt sich der Kernel nicht dreinreden, was er festlegt, gilt eisern. Aber alles Philosophieren nützt nicht, wir brauchen Fakten. Und wir dürfen nicht vergessen, daß Hersteller in Bereichen, die nicht von einem "dd if=/dev/sdX" erfaßt werden, manchmal Dinge speichern, die nicht ganz das Wahre sind (und Windows auch nicht stören, und das ist ja das für sie Entscheidende).
 
OP
G

goeba

Hacker
Ok, danke. Ich werde versuchen, die relevanten Infos nachzureichen. Einfacher wäre es, wenn ich selbst so einen Stick hätte, aber komischerweise wollen die Leute ihre Sticks immer nicht für längere Zeit hergeben ...
 

muck19

Hacker
Ich kenne das so - wenn die Sticks an einem Win Rechner formatiert und beschrieben wurden, dann gehört der Stick root.
 
OP
G

goeba

Hacker
Nein, das ist definitiv nicht so. Ich habe zu Testzwecken einen Stick unter Windows mit verschiedenen Dateisystemen formatiert, weil ich erst dachte, es läge daran. Aber egal ob Fat32, Fat16, Ntfs oder sogar exfat, dieser Stick wurde immer automatisch als user ohne root-Rechte eingebunden (exfat erforderte allerdings Installation der Unterstützung für dieses Dateisystem).

Es liegt irgdendwo am Zusammenspiel der Hardware dieser Sticks und OpenSuse13.2, evtl. auch an der speziellen Installation auf unseren Clients. Das Problem kommt aber häufiger vor, nur dass man es an einem Einzelrechner leicht lösen kann durch Eingabe des root Passwortes.

Die beiden Sticks, bei denen das auftrat, waren beide recht groß (der eine 8 GB, der andere 16), aber nur daran kann es auch nicht liegen, ein anderer 16 GB Stick wurde problemlos eingebunden.
 
A

Anonymous

Gast

josef-wien

Ultimate Guru
Versuchen kann man vieles, aber nachdem nur einzelne Sticks betroffen sind, halte ich einen Käfer für wenig wahrscheinlich. Nebenbei bemerkt gibt es nach 13.2 in den offiziellen openSUSE-Repos keinen kernel-desktop mehr.
 
A

Anonymous

Gast
Der Andreas betreut ja viele Rechner. Er könnte auf einem einzigen Kernel 3.18 installieren und am Montag dort einen "buggy" Stick gegenchecken.
Und ja. Er müsste ein home: Repo benutzen.

Kennt jemand aus dem Forum den oder die Leute, die einen passenden Kernel zusammengebaut haben?
 
OP
G

goeba

Hacker
@LUH: Natürlich wäre es kein Problem, an einem einzelnen Rechner einen anderen Kernel zu installieren. Ich hätte aber keine große Lust, das an 100 Rechnern zu machen, aber rein interessehalber an einem natürlich schon. Wer also einen geeigneten Kernel aus einem geeigneten Repo weiß, immer her damit.

@josef-wien : Auch nochmal zur Nachfrage

Code:
org.freedesktop.udisks2.filesystem-mount-system         auth_admin:auth_admin:yes

in /etc/polkit-default-privs.local (diese Datei gibt es bei mir nicht, die würde ich also neu anlegen) würde bewirken, dass Leute aus der Gruppe "user" beliebige Laufwerke einbinden dürfen, ja? Das Risiko, dass das jemand missbraucht, scheint mir gering.

Zusätzlich den Befehl aus der Datei ausführen: Das dient dazu, dass die Änderungen gleich ohne Neustart wirksam werden, ja?

Diese Lösung hätte den Charme, dass man die zusätzliche Datei polkit-default-privs.local problemlos auf die Clients automatisch verteilen könnte.

Danke Euch, Andreas
 

josef-wien

Ultimate Guru
goeba schrieb:
Wer also einen geeigneten Kernel aus einem geeigneten Repo weiß
Ich würde kernel-default 4.1 von 42.1 nehmen.

goeba schrieb:
/etc/polkit-default-privs.local
Ich kenne 13.2 nicht und kann daher nicht sagen, ob sich die "polkit-Philosophie" seit 13.1 geändert hat. Das Paket polkit-default-privs gibt es jedenfalls noch, und wenn es installiert ist, muß auch die genannte Datei vorhanden sein. Das Ändern der Datei bewirkt noch gar nichts, aus den Eintragungen müssen gültige polkit-Regeln erzeugt werden. Was ergibt als root:
Code:
ls /etc/polkit*
pkaction --action-id org.freedesktop.udisks2.filesystem-mount-system --verbose
grep -A1 org.freedesktop.udisks2.filesystem-mount-system /etc/polkit-1/rules.d/*
 
OP
G

goeba

Hacker
Die Datei ist da, da muss ich mich vertippt / verguckt haben.

Ok, Montag bin ich schlauer.

Andreas
 
OP
G

goeba

Hacker
Hallo,

ich habe heute viele der genannten Befehle ausprobiert, die Ergebnisse auch gespeichert. Das poste ich morgen, ich wollte nur schon mal sagen, dass

Code:
org.freedesktop.udisks2.filesystem-mount-system         auth_admin:auth_admin:yes

funktioniert hat. Der betreffende Stick (und die anderen hoffentlich auch) lässt sich jetzt vom User mounten. Es kommt allerdings kein Hinweis in KDE "was möchten Sie mit dem Stick machen", und er wird dann auch als Felstpaltte, nicht als Wechselmedium, eingebunden. Damit sollten meine User aber klarkommen.

Der Haken an der Sache ist nun wohl, dass wir auf ein paar Rechnern parallel noch Windows drauf haben, und nun können normale User die Windows Partitionen mounten. Naja, hoffentlich kommt da keiner auf die Idee, was kaputt zu machen.

Ich poste dann morgen, was die anderen Kommandos für Ergebnisse brachten.

Vielen Dank Euch allen,

Andreas
 
OP
G

goeba

Hacker
Hallo,

ich schau mir das morgen mal an, wie das an den Dual-Boot-Kisten aussieht.

Hier jetzt noch die Ausgaben von fdisk und udevadm:

Code:
fdisk -l


Device     Boot Start      End  Sectors  Size Id Type
/dev/sdb1        2776 15482879 15480104  7,4G  b W95 FAT32


journalctl -f

-- Logs begin at Mi 2015-11-11 15:59:17 CET. --                         
Dez 07 12:09:49 m358 kernel: sd 3:0:0:0: [sdb] Attached SCSI removable disk
Dez 07 12:10:01 m358 cron[3874]: pam_unix(crond:session): session opened for user root by (uid=0)                                                      
Dez 07 12:10:01 m358 systemd[3875]: pam_unix(systemd-user:session): session opened for user root by (uid=0)
Dez 07 12:10:01 m358 CRON[3874]: pam_unix(crond:session): session closed for user root
Dez 07 12:10:01 m358 systemd[3877]: pam_unix(systemd-user:session): session closed for user root
Dez 07 12:10:36 m358 kernel: SFW2-INext-ACC-TRUST IN=enp0s25 OUT= MAC=00:0f:fe:6b:53:0a:0c:c4:7a:69:a7:dc:08:00 SRC=10.0.0.5 DST=10.0.12.193 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=39202 DF PROTO=TCP SPT=56597 DPT=22 WINDOW=14600 RES=0x00 SYN URGP=0 OPT (020405B40402080A218266A10000000001030307) 
Dez 07 12:10:36 m358 sshd[3903]: Accepted publickey for root from 10.0.0.5 port 56597 ssh2: DSA 5c:d5:8d:e2:61:f0:43:18:ce:45:9c:6e:5d:f6:ff:70 [MD5]
Dez 07 12:10:36 m358 sshd[3903]: pam_unix(sshd:session): session opened for user root by (uid=0)
Dez 07 12:10:36 m358 systemd[3905]: pam_unix(systemd-user:session): session opened for user root by (uid=0)
Dez 07 12:11:06 m358 kernel: SFW2-INext-ACC-TRUST IN=enp0s25 OUT= MAC=01:00:5e:00:00:fb:0c:c4:7a:69:a7:dc:08:00 SRC=10.0.0.8 DST=224.0.0.251 LEN=218 TOS=0x00 PREC=0x00 TTL=255 ID=49307 DF PROTO=UDP SPT=5353 DPT=5353 LEN=198 


langoebe@m358:~> /sbin/udevadm info -a -p $(/sbin/udevadm info -q path -n /dev/sdb1)

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/pci0000:00/0000:00:1a.7/usb5/5-3/5-3:1.0/host4/target4:0:0/4:0:0:0/block/sdb/sdb1':
    KERNEL=="sdb1"
    SUBSYSTEM=="block"
    DRIVER==""
    ATTR{ro}=="0"
    ATTR{size}=="15480104"
    ATTR{stat}=="      66       54      960      164        0        0        0        0        0      132      164"
    ATTR{partition}=="1"
    ATTR{start}=="2776"
    ATTR{discard_alignment}=="0"
    ATTR{alignment_offset}=="0"
    ATTR{inflight}=="       0        0"

 
udisksctl mount --block-device /dev/sdb1
Error mounting /dev/sdb1: GDBus.Error:org.freedesktop.UDisks2.Error.NotAuthorized: Not authorized to perform operation
langoebe@m358:~>
(hier wurde nach dem root-KW gefragt).

Das war natürlich, bevor ich die polkit-Angaben geändert hatte.
 
Oben