permissions von /dev/parport0 und anderen files...

[h-man]

bisher änderte ich die permissions und ownership von /dev/parport0 jeden tag "von hand" per chown und chmod, weil ich möchte, daß ein user in der gruppe lp zugriff auf diese datei haben soll.

jetzt hatte meine faulheit zugeschlagenund ich wollte das teufelchen finden, welches die permissions immer wieder so restriktiv zurücksetzt. vor ein paar jahren gab es doch mal ein packet mit check-permissions oder checksecurity oder so ähnlich.

jedenfalls ist ein solches packet bei mir NICHT installiert. ein beherztes:
dpkg --get-selections | grep -E secur\|perm\|check || echo nix gefunden
gibt aus: "nix gefunden"

dann suchte ich im /etc nach dem üblen script, welches meine permissions immer wieder restriktiv einstellt.
per "grep -R chmod /etc" fand ich einige scripte, die chmods machen, aber ich konnte keines finden, welches /dev/parport* ändert...

also früher ging das jedenfalls noch, daß mir niemand windowisch in mein rechtemanagement reingepfuscht hat. kann mir jemand auf die sprünge helfen, was man jetzt bei debian abschalten muß?

grüße, h-man

[KBDCALLS]

Falls udev installiert

Code: Alles auswählen

 
/etc/udev/permissions.d/udev.permissions
/etc/udev/permissions.rules

[h-man]

danke für den hinweis. udev ist bei mir installiert, aber da ich kernel 2.4.x benutze, sollte es eigentlich nix tun? aber wie auch immer, ein grep -R parport /etc/udev liefert genau eine
zeile: "/etc/udev/devfs.rules:KERNEL="parport[0-9]*", NAME="parports/%n"" und die macht nicht den eindruck, daß da permissions gesetzt werden.

die doku in "/usr/share/doc/udev/writing_udev_rules/index.html" erwähnt das wort perm überhaupt nirgends...

udev scheint mir ein wenig undurchsichtig zu sein, sieht aus wie so eine krücke für plug&play funktionalität mit vielen zugeständnissen an ein hoffentlich vorhandenes konzept.

gibt es das wegen der ganzen zu linux umgeschwenkten windowsbenutzer oder wegen dieser neumodischen "usb-sticks"???

leider packt debian das udev paket so, daß u.a. gnome-volume-manager davon abhängig ist und damit das ganze gnome... oh weh.

[KBDCALLS]

udev scheint mir ein wenig undurchsichtig zu sein, sieht aus wie so eine krücke für plug&play funktionalität mit vielen zugeständnissen an ein hoffentlich vorhandenes konzept.

gibt es das wegen der ganzen zu linux umgeschwenkten windowsbenutzer oder wegen dieser neumodischen "usb-sticks"???

leider packt debian das udev paket so, daß u.a. gnome-volume-manager davon abhängig ist und damit das ganze gnome... oh weh.

Macht irgendwie nicht so richtig Sinn , udev ist nur für Kernel 2.6.xx .

Ein

Code: Alles auswählen

apt-cache depends gnome-volume-manager |grep udev

ergibt nichts.

und

Code: Alles auswählen

apt-cache rdepends gnome-volume-manager |grep udev

auch nichts.

Der devfsd könnte auch noch seine Finger im Spiel haben.

[h-man]

leider packt debian das udev paket so, daß u.a. gnome-volume-manager davon abhängig ist und damit das ganze gnome... oh weh.

Macht irgendwie nicht so richtig Sinn , udev ist nur für Kernel 2.6.xx .

Ein

Code: Alles auswählen

apt-cache depends gnome-volume-manager |grep udev

ergibt nichts.

und

Code: Alles auswählen

apt-cache rdepends gnome-volume-manager |grep udev

auch nichts.

Der devfsd könnte auch noch seine Finger im Spiel haben.

Das mit der Abhängigkeit stimmt, bei mir ergibt das "apt-cache depends..." auch nichts. Aber wenn ich versuche den udev zu löschen mit "apt-get --purge remove udev" will er den gnome-volume-manager und hal auch entfernen. Mal gucken woran das liegen mag...

devfsd ist bei mir nicht installiert und mit devfs hatte ich noch nie gearbeitet (jedenfalls nicht freiwillig. In der Firma hatten die das leider mal installiert und ich mußte die probleme mit den gerätenamen lösen)

Irgendwann überliste ich das plugNplay schon noch