On Sunday 18 September 2005 03:45, Kyle Moffett wrote:
> On Sep 17, 2005, at 18:31:33, D. Hazelton wrote:
> > That, and my point remains that the kernel should know absolutely
> > nothing about how to execute a text file - the kernel should
> > return an error to the extent of "I don't know what to do with
> > this file" to the shell that tries to execute it, and the shell
> > can then check for the sh_bang. I do admit that this change would
> > break a lot of existing code, so I'll leave the argument to the
> > experts.
>
> No, that would not work at all. We have a very nice system to
> allow set-uid scripts (Specifically, I like my nice secure
> taint-mode set- uid perl scripts). If you did this, they would
> break completely, not to mention _add_ all sorts of unsolvable race
> conditions to the few ways of working around such a lack of SUID
> scripts. Also, it means that I can't just "mv /sbin/init
> /sbin/init.real ; vim /sbin/init" to do a simple wrapper around the
> init program, I would need to write a compiled C program to do all
> sorts of fragile hackish things like calling a script
> /sbin/init.sh.
This makes a lot more sense than I expected to hear. This argument
alone is enough for me to understand the reasoning behind the kernel
knowing how to interpret a shell script. Problem is, the program
would not be fragile or hackish - it'd be almost as simple as a
"hello world" program.
#include <unistd.h>
int main() {
/* if this fails the system is busted anyway */
return execve( "/bin/sh", "/sbin/init.sh", 0 );
};
-- This program would do the trick nicely, and since init is run as
root, there is no need to worry about the program having to grab
privs.
However, the real problem is that this would break the initrd systems
used by most distributions for installation, and it would probably
break most of the "early userspace" systems just coming into use. As
I said originally - my comment about having the shell itself
interpret the sh_bang would break a lot of stuff and I've been shown
that I have to spend more time in the kernel code (as I haven't
finished going through the various drivers to see how those have been
made to work) before I can make a good suggestion in a discussion
like this.
DRH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |