* User does 'head /dev/scd0'.
* The kernel runs modprobe block-major-11. modprobe is running
setuid(0) because the original user was not root.
* modprobe maps block-major-11 to sr_mod.
* modprobe sees a pre-install command for sr_mod and uses system() to
invoke the command.
* The system() function issues '/bin/sh -c "command"', sh is linked to
bash.
* Bash detects that it was invoked as 'sh' and is running setuid. Bash
silently turns off the setuid privilege before running the command.
WRONG!!
* The second command (modprobe ide-scsi) needs root authority but bash
has removed the authority. modprobe fails :(
The problem is caused by a bash "feature", it was added in bash 2.01.
I cannot fix it without writing my own replacement for the system()
function. Doing setuid(0) in modprobe before calling system() would
reopen the security exposure that was closed in modutils 2.3.21, that
is not an option.
Workaround: Replace
pre-install foo modprobe bar
with
before foo bar
That does all the work internally without using the system() function
and falling foul of the bash feature. It is also faster and it lets
modprobe maintain the chain of modules for unload.
BTW, users can never run rmmod, only root can do that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/