Re: Executable shell scripts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, May 13, 2006 at 02:23:30PM +0200, Mark Rosenstand wrote:
> (Cutting Arjan off the CC list, he's been bugged enough for his attempt
> to help.)
> 
> Bernd Petrovitsch <[email protected]> wrote:
> > On Sat, 2006-05-13 at 13:45 +0200, Mark Rosenstand wrote:
> > > Bernd Petrovitsch <[email protected]> wrote:
> > > > On Sat, 2006-05-13 at 13:03 +0200, Mark Rosenstand wrote:
> > > > [...]
> > > > > A more useful case is when you setuid the script (and no, this doesn't
> > > > > need to be running as root and/or executable by all.)
> > > > 
> > > > Apart from the permission bug: This has been purposely disabled since it
> > > > is way to easy to write exploitable shell or other scripts.
> > > > Use a real programming languages, sudo or a trivial wrapper in C ....
> > s/languages/language/
> > 
> > And I forgot to mention that a kernel patch is another possibility.
> 
> I'm too stupid to provide such myself, but I'd sure enable the Kconfig
> option if it was there :)
> 
> > > It isn't a bug on systems that support executable shell scripts.
> > 
> > I never wrote that (or anything which implies that directly).
> 
> I was commenting on the "Apart from the permission bug" part.
> 
> > > Doing security policy based on programming language seems weird at
> > > best, especially when the only user able to make those decisions is the
> > > superuser.
> > 
> > It boils down to "how easy is it for root to shoot in the foot"?
> > And the workarounds are somewhere between trivial and simple.
> 
> Or "dare we handle root a gun, it's a powerful weapon but can be used
> to shoot at feet." It's obvious what the answer have been for that in
> other operating systems, and probably one of the reasons we're here.

Well, at first I thought you did not understand how permissions work. I
apologize for this, but your question was not clear at all. I've checked
on OpenBSD and can confirm that it works. However, it does not exactly
work, it passes /dev/fd/3 to the shell as Neil suggested it. Moreover,
argv[0] gets changed to /dev/fd/3 when the script is not readable, not
very useful :

$ cat > foo
#!/bin/sh
echo \$0=$0 \$1=$1 ...

$ chmod 755 foo
$ ./foo bar
$0=./foo $1=bar ...

$ chmod 111 foo
$ ./foo bar
$0=/dev/fd/3 $1=bar ...

So the very common dirname or ${0%/*} tricks used to get the execution
directory from the running script will not work. Worse, behaviour will
have to be validated both with AND without read permissions since it
works differently in both cases.

At least, feeding the script to stdin and renaming argv[0] to point to
it would have been better.

Regards,
Willy

-
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]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux