Hallo, On Sun, 24 Feb 2002, Lars Mucha wrote:

David Haller wrote:

...

Kannst du insmod / modprobe als user ausfuehren? Natürlich nicht. Aber mount hat doch das s-Bit gesetzt.

-rwsr-xr-x 1 root root 78k Mar 3 2001 /bin/mount

Is egal. Die Module werden nicht von mount geladen (siehe z.B. 'strace -eprocess mount ...' als root). Probier's einfach mal aus. Setze das suid-bit auf insmod... (du kannst ja z.B. eine gesonderte Gruppe fuer diesen Zweck anlegen und dann 'chmod 4750'. -dnh -- [Re : quantum physics] "I can't say I care one way or another." -- Kai Henningsen "That's just because nobody's measured you yet." -- Christian Bauernfeind

Hallo, On Wed, 27 Feb 2002, Lars Mucha wrote:

David Haller wrote:

...

Is egal. Die Module werden nicht von mount geladen (siehe z.B. 'strace -eprocess mount ...' als root). Probier's einfach mal aus. Setze das suid-bit auf insmod... (du kannst ja z.B. eine gesonderte Gruppe fuer diesen Zweck anlegen und dann 'chmod 4750'. Öffnet das nicht eine riesige Sicherheitslücke, wenn insmod suid ist?

Deswegen der Vorschlag mit der Gruppe... Im rpm der modutils 2.4.12 von kernel.org sind die Rechte so (gekuerzt): -rwxr-xr-x 1 root root [..] /sbin/insmod -rwxr-xr-x 1 root root [..] /sbin/insmod.static Im 7.2er SuSE-rpm sind die Rechte genauso. Was ich mir nun vorgestellt habe ist z.B.: -rwsr-x--- 1 root modutils [..] /sbin/insmod -rwsr-x--- 1 root modutils [..] /sbin/insmod.static Ideal finde ich die Loesung aber auch nicht, logisch. Jedes gesetzte SUID-Bit ist eins zuviel... Irgendwie werde ich aber das Gefuehl nicht los, dass das ganze ein Bug ist, denn bis inkl. 2.4.0-test4 (der Kernel, den ich vor dem z.Z verwendeten 2.4.16 verwendet habe) hat das mit diesen Rechten auch geklappt... Achso: Ich hab hier modutils 2.4.6, laut Changes zum Kernel sollten die 2.4.2 reichen, werde aber evtl. mal mit ner aktuellen Version testen... -dnh --

Wonder what diamonds do to lusers, though. Black diamonds generally make them tumble bouncy-bouncy down steep mogul-filled slopes. Sometimes over cliffs, too. Whee! From the lodge we shout encouragement. "Down, not Across!" [G. Andrews, asr]

Hi,

From the keyboard of David,

Hallo,

On Wed, 27 Feb 2002, Lars Mucha wrote:

...

David Haller wrote:

...

Is egal. Die Module werden nicht von mount geladen (siehe z.B. 'strace -eprocess mount ...' als root). Probier's einfach mal aus. Setze das suid-bit auf insmod... (du kannst ja z.B. eine gesonderte Gruppe fuer diesen Zweck anlegen und dann 'chmod 4750'. Öffnet das nicht eine riesige Sicherheitslücke, wenn insmod suid ist?

Deswegen der Vorschlag mit der Gruppe...

Auch das ist nicht sinnvoll. Ein User sollte nicht Kernelspace verändern dürfen, noch besser kann man sein System nicht genauso *sicher* machen wie ein Windoof. Sorry aber das ist totaler Quatsch das zutun. gruß Waldemar -- Are your questions smart enough? http://www.tuxedo.org/~esr/faqs/smart-questions.html If not: perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'

Hallo David and others,

From the keyboard of David,

Hallo,

On Sat, 02 Mar 2002, Waldemar Brodkorb wrote:

...

...

From the keyboard of David, On Wed, 27 Feb 2002, Lars Mucha wrote:

...

David Haller wrote:

...

Is egal. Die Module werden nicht von mount geladen (siehe z.B. 'strace -eprocess mount ...' als root). Probier's einfach mal aus. Setze das suid-bit auf insmod... (du kannst ja z.B. eine gesonderte Gruppe fuer diesen Zweck anlegen und dann 'chmod 4750'. Öffnet das nicht eine riesige Sicherheitslücke, wenn insmod suid ist?

Deswegen der Vorschlag mit der Gruppe...

Auch das ist nicht sinnvoll. Ein User sollte nicht Kernelspace verändern dürfen, noch besser kann man sein System nicht genauso *sicher* machen wie ein Windoof.

Prinzipiell Ack.

...

Sorry aber das ist totaler Quatsch das zutun.

Aber wie willst du's sonst machen? Fest in den Kernel?

Ja. Einerseits, wenn man eine Hardware ansprechen will spricht nix dagegen das fest in den Kernel zu integrieren, anderseits verliert man die Flexibilität. Das Modulsystem ist am Anfang eigentlich nur für Treiberentwickler gedacht gewesen, da man beim Kerneldevelopment auch keine Lust hat ständig neu zu booten, um seinen Treiber zu testen/debuggen. Für den Endanwender ist es aber auch sehr nützlich, da man nicht mit einer heftig langen append-Zeile arbeiten muß wenn man seine Hardware auf seinen Wunsch hin konfigurieren möchte.

Und wenn das mal nicht geht (z.B. bei lp.o vs. ppa.o/imm.o, die koennen nicht beide gleichzeitig geladen werden)? Willst du dich dann immer als root einloggen? Oder sudo[1]? Und v.a.: wie gesagt, bis mind. 2.4.0-test4 gings ohne das suid-bit auf insmod.

Warum nicht. Spricht doch nichts dagegen für solche Tätigkeiten sich kurz ne root-Shell aufzumachen.

Also bitte nicht nur pauschal als Quatsch abtun, sondern bitte auch eine Loesungsmoeglichkeit vorschlagen... Mir ist jedenfalls keine eingefallen... :(

Ich habe das Problem auch nicht ganz verstanden, bin gestern schon den Thread kurz durchgegangen und da wurde alles gesagt. Was spricht denn dagegen die Unterstützung des Adaptecs beim booten zu zu laden. (z.B. durch boot.local oder durch eine korrekte Konfiguration der modules.conf)

Ich hab bei mir auf meiner Kiste, auf der nur ich arbeite und spiele, mit einem etwas unguten Gefuehl eben das suid-bit gesetzt, denn, auch wenn ich nicht als root eingeloggt bin, "Ich bin root, ich darf das" ;) Ist also nur ne Frage der Bequemlichkeit bei _mir_.

sudo ist auch bequem, macht aber in dem Fall die Sache genau so unsicher.

Auf nem Server wuerde ich in der Situation halt soviel wie moeglich fest in den Kernel backen...

Jupp, auf meinem Router ist zum Beispiel Modulsupport deaktiviert .. paranoid halt ;)

-dnh

[1] Wie definiert man in sudoers eigentlich Befehle mit Argumenten? Bei mir will das einfach nicht klappen...

man sudo man sudoers Feine EBNF-Beschreibung der Syntax mit vielen Beispielen. man visudo Der meckert dann auch wenn du was falsch verstanden hast :) gruß Waldemar -- Are your questions smart enough? http://www.tuxedo.org/~esr/faqs/smart-questions.html If not: perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'

Hallo Lars,

From the keyboard of Lars,

Es gibt Module, die können nicht parallel geladen werden (z.B. capi und hisax).

Da hast du aber ein schlechtes Beispiel gewählt. Nenne mir einen Anwendungsfall wo das Sinn machen würde diese beiden Module gleichzeitig zu laden?

Und manche Sachen benötigen noch weitere Module, um zu funktionieren.

Das geht aber grundsätzlich automatisch! Mit depmod -a werden die Abhängigkeiten zwischen den Modulen erzeugt. (ist ne ascii-datei --> /lib/modules/2.4.18/modules.dep) Bsp.: /lib/modules/2.4.18/kernel/drivers/media/video/bttv.o: /lib/modules/2.4.18/kernel/drivers/i2c/i2c-core.o \ /lib/modules/2.4.18/kernel/drivers/i2c/i2c-algo-bit.o \ /lib/modules/2.4.18/kernel/drivers/media/video/videodev.o Wenn ich jetzt modprobe bttv mache, wird automatisch i2c-core.o,i2c-algo-bit.o und videodev.o mit in den Kernelspace geladen und registriert, und zwar vor bttv.o.

Meine Frage war daher nur genereller Natur, warum das Nachladen der Module nicht automatisch funktioniert. Aus Bequemlichkeit möchte ich mich nicht immer als root anmelden, nur um auf CD zugreifen zu können.

Deswegen gibt es die sehr sinnvolle Erfindung des automounter's. Der regelt das für einen, wäre ja schon ziemlich blöd wenn man immer manuell mount/umount benutzen würde, nur um mal ne Datei zu kopieren.

Fazit ist, dass das anscheinend ein Kernelbug ist, wie von David angemerkt wurde.

Ok, es könnte ein Bug sein, sowas kann man nicht auschließen, aber dann eher im speziellen Modul und weniger im Modulladealgorithmus, der fest im Kernel integriert ist.

Wegen der Sicherheit werde ich auch weiterhin das CD-ROM als root mounten. Das suid-gesetzte insmod behagt mir nicht so.

Meine Worte. gruß Waldemar -- Are your questions smart enough? http://www.tuxedo.org/~esr/faqs/smart-questions.html If not: perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'

Hallo David and others,

From the keyboard of David,

...

Ich habe das Problem auch nicht ganz verstanden, bin gestern schon den Thread kurz durchgegangen und da wurde alles gesagt. Was spricht denn dagegen die Unterstützung des Adaptecs beim booten zu zu laden. (z.B. durch boot.local

Sowas halte ich fuer eine recht sinnfreie Loesung, dann kann man's auch gleich fest einkompilieren. Der Sinn der module ist ja eben, dass man die _nicht_ staendig laedt... Wuerde aber gehen, sofern man nicht 2 Module abwechselnd laden muss (lp/ppa z.B.).

Hast recht optimal ist es nicht in boot.local, mehr ala Würgaround, aber was soll's, hauptsache man kann die Hardware hinterher benutzen :)

...

oder durch eine korrekte Konfiguration der modules.conf)

Das isses doch, meine modules.conf _ist_ korrekt. Wie du an dem Beispiel von mir sehen konnest klappt mit suid-bit das mounten ja (inkl. dem laden der noetigen Module: ide-scsi, scsi_mod, cdrom und sr_mod).

Hmmm, sie ist korrekt? Dein System ist zu alt, du zählst nicht! *fg* Vorallem haste zuviel rumgefuscht , hehe

Apropos: mein visudo setzt die Rechte flasch...

Bestätigt obige Aussage *g* gruß Waldemar -- Are your questions smart enough? http://www.tuxedo.org/~esr/faqs/smart-questions.html If not: perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'

Hi David,

From the keyboard of David,

Hallo,

On Sun, 03 Mar 2002, Waldemar Brodkorb wrote:

...

...

From the keyboard of David, [modprobe in boot.local] Hast recht optimal ist es nicht in boot.local, mehr ala Würgaround, aber was soll's, hauptsache man kann die Hardware hinterher benutzen :)

Ja.

...

...

...

oder durch eine korrekte Konfiguration der modules.conf)

Das isses doch, meine modules.conf _ist_ korrekt. [..]

Wobei, da faellt mir (wg. deiner Antwort zu Lars' Mail) ein: muss mal testen, ob's z.B. mit bttv auch ohne suid-bit klappt...

...

Hmmm, sie ist korrekt?

Ja. Und erprobt. Und fuer jeden Kernel angepasst gepflegt. ;)

...

Dein System ist zu alt, du zählst nicht! *fg*

Ach?

$ uname -a Linux slarty 2.4.16-1 #5 Fri Dec 14 01:59:45 CET 2001 i686 unknown $ rpm -q modutils modutils-2.4.6-1

Ich denke, in dem Teil um den's geht ist mein System aktueller als z.B. ne SuSE 7.2...

Aber ob das reicht bei der hohen Fluktuation von neuer Software aus der OpenSource Scene ... /sbin/insmod -V insmod version 2.4.13 uname -a Linux hawkeye 2.4.18 #1 Die Feb 26 01:00:04 CET 2002 i686 unknown

*scnr*

cnr, too *g*

...

Vorallem haste zuviel rumgefuscht , hehe

So eine ueble Unterstellung! *g*

Ok, bevor es hier wieder zu philosophischen Diskussionen kommt, möchte ich mich *öffentlich*, zutiefst bedrückt deswegen, bei dir vielmals um entschuldigung bitten! ROFL ;) gruß Waldemar -- Are your questions smart enough? http://www.tuxedo.org/~esr/faqs/smart-questions.html If not: perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'

Lars Mucha schrieb:

David Haller wrote:

...

On Wed, 20 Feb 2002, Lars Mucha wrote:

...

Hab hier ein SCSI-CD am Adaptec. Wenn ich als root das Laufwerk mounte, klappt alles. Mach ich das als User (man soll ja nicht als root arbeiten), dann geht das nicht. Fehlermeldung: /dev/sr0 ist kein gültiges Blockdevice.

...

Kannst du insmod / modprobe als user ausfuehren?

Hab ich mal freigegeben, so dass der User die Programme aufrufen darf. Trotzdem ändert sich nichts. Noch Ideen?

Was spricht dagegen, die Devices einfach per boot.local zu laden? Dies sollte das Problem ja durchaus lösen können. Mit den besten Grüßen, Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53

Hallo, On Wed, 27 Feb 2002, Peter Kuechler wrote:

Am Mit, 2002-02-27 um 09.04 schrieb Konrad Neitzel:

...

Lars Mucha schrieb:

...

David Haller wrote:

...

Kannst du insmod / modprobe als user ausfuehren?

Ich verstehe nicht ganz, warum das nötig sein soll. Der kernel stellt fest, das er ein Modul benötigt und versucht das selbe zu laden. Warum soll der User deswegen insmod / modprobe ausführen können??

Wegen folgendem (hab mal das suid-bit geloescht und die module entladen): root@slarty # ls -l /sbin/insmod -rwxr-x--- 1 root users 112215 Jun 7 2001 /sbin/insmod* dh@slarty $ mount /cdrec/ mount: /dev/cdrec is not a valid block device root@slarty # chmod u+s /sbin/insmod root@slarty # ls -l /sbin/insmod -rwsr-x--- 1 root users 112215 Jun 7 2001 /sbin/insmod dh@slarty[1]:~ (32) $ mount /cdrec/ dh@slarty[1]:~ (0) $ mount | grep cdrec /dev/sr1 on /cdrec type iso9660 (ro,noexec,nosuid,nodev,mode=0440,uid=500,gid=100,user=dh) (in den "()" im Prompt steht der Exitstatus des vorausgegangenen Befehls also das (32) ist das vom fehlgeschlagenenen mount...) Fazit: Es gibt offensichtlich einen Zusammenhang zwischen den Rechten auf insmod und dem laden (koennen) von Modulen als user. Die Meldung "is not a valid block device" kommt dabei, weil sr_mod (und der Rest) nicht geladen werden konnte/durfte. In der "messages" finden sich dann auch die passenden Meldungen: slarty insmod: /lib/modules/2.4.16-1/kernel/drivers/cdrom/cdrom.o: pre-install sr_mod failed slarty insmod: /lib/modules/2.4.16-1/kernel/drivers/cdrom/cdrom.o: insmod block-major-11 failed Achso: an den Rechten auf die modules.conf, den modules selbst, oder des devices liegts nicht. -dnh -- 82: Demokratie Statt eines Hofnarren für den König gibt es ein paar hundert für das Volk. (Stefan Hager)

Hallo, On Wed, 27 Feb 2002, Conrad Gliem wrote:

On Wed, 27 Feb 2002, David Haller wrote:

...

On Wed, 27 Feb 2002, Peter Kuechler wrote:

...

Ich verstehe nicht ganz, warum das nötig sein soll. ACK

Ahem, nur so nebenbei: Kannst du mir mal erklaeren, wieso du auf meine Mail antwortest, und nicht direkt auf Peter's, wenn du dich eh nur auf seine beziehst? -dnh, leicht irritiert... -- The only possible interpretation of any research whatever in the "social sciences" is: some do, some don't. -- Ernest Rutherford