On Tue, 8 Jul 1997, Craig Sanders wrote:
> On Tue, 8 Jul 1997, Alexander Kjeldaas wrote:
>
> > You are just plain wrong. Perl has syscall which makes it possible to do
> > _anything_. You can't to _anything_ with sed. As for awk - I don't use
> > it.
>
> I said "sh + sed + awk + cut + (all the other useful unix
> utilities)"...i.e. i was referring to them as a suite of useful &
> related tools to be used in combination with each other - name one thing
> that perl can do which these tools can not.
network programming.
>
> to paraphrase you: "sh can execute arbitrary programs, which makes it
> possible to do _anything_".
Yes. If the appropriate programs are available. You can do network
progamming in /bin/sh if you have netcat for example. If you don't have
netcat and you can't introduce it then you can't to network programming.
When you reach a certain "critical" mass of programs on the system,
/bin/sh becomes pretty powerful.
> I presume that you are not so excessively paranoid as to remove /bin/sh
> - please explain to me how bash or sh or csh is NOT a "powerful
> interpreter".
Hmm.. "powerful" is probably a confusing term because I don't refer to the
power of expression possible in a given scripting language. What I refer
to are the features the scripting language provides. Perl provides direct
access to the kernel through the syscall interface. /bin/sh provides
access to the executables on the system.
This means that you cannot always do the same with /bin/sh as with perl -
that's why I call /bin/sh less "powerful".
> > Please tell me how - given the following setup:
> >
> > * All filesystems are read-only.
>
> then what is your problem?
>
/var isn't read-only (point nr. 4).
> if the filesystems are read-only or noexec then why are you so worried
> about people creating new executables?
In my mind, exec /var/tmp/evil-script, perl /var/tmp/evil-script, and
variations are all the same. Disallowing new executables are only
meaningful in order to disallow to introduce new interpreters.
> BTW, you seem to be changing your story to suit your argument. At first
> you said that "It doesn't seem to be possible to do that with debian
> yet.", but the ultra-paranoid setup you describe can be done on any
> unix.
I'm pointing out that if you need perl to maintain a debian-based system,
you have a "powerful" interpreter in the house. My ultra-paranoid setup
which tries to avoid pepole from introducing new executables into the
system doesn't make any sense in a system where perl is installed because
anybody can make a perl-script.
> > I don't think you listen to me - I don't want powerful interpreters so
> > perl doesn't _exist_ - you'll have to introduce it into the system first.
>
> i did read what you said. I just think you are worrying about nothing.
>
> also, you are not reading what I wrote - the reference to "perl
> myprog.pl" and "sh myprog.sh" were hypothetical example showing why it
> is pointless to search for files which have the execute bit set.
Yes it's pointless _iff_ there's an interpreter on the system, so powerful
that the difference between a script and an executable is blurred.
> Whining about debian including perl is not at all productive. If you don't
> want perl, then don't install it. simple as that. it's your choice.
>
> If there are some packages available for debian which use scripts
> written in perl, then you are at perfect liberty to write your own
> versions of the offending scripts in any language you choose.
>
> Just don't expect to be able to force every volunteer developer to cater
> exclusively to your bizarre needs.
My bizarre needs are that perl _should not_ be used to implement the
end-user administration system and {post,pre,whatever}* scripts.
> Debian is a general purpose linux distribution, providing a good
> selection of the tools which are expected on any modern unix - if you
> need it to be or do something truly weird then it is up to you to make
> whatever modifications are necessary. If what you produce is good, then
> feel free to contribute it back to the project for others to benefit
> from your hard work. *That* is how debian grows.
>
> > > in other words, the only way to do it on any unix is to be vigilant, and
> > > to make sure your users understand what they are and are not allowed to
> > > do on your system.
> >
> > You assume I have users on my systems - that isn't necessarily true.
>
> so what are you so worried about? If you don't have users on the system
> then WHO, apart from you, is going to be installing extra programs? Don't
> you even trust yourself?
On a server, if somebody breaks in, I don't want them to find perl, gcc
etc. [The above setup works for multi-user systems as well. Users will
have specific tasks to do. There will be some writable partition that
contains data the users should modify. ]
> > Because if you want others to make "specialized" distributions they might
> > not be interested in having the run-time system of a dozen languages on
> > their system. If the distribution is 40MB you don't want that 20MB of that
> > consists of slang, perl and java run-time support.
>
> the base distribution is nowhere near 40mb in size. you exaggerate wildly.
I wasn't referring to the size of the _debian_ base system, but the size
of some "specialized" distribution.
As to the size of a minimal debian system, I don't think it's much less
than 18MB as indicated by my initial posting. According to dselect, you
are right that 20MB for slang, perl and java support is too much - perl is
about 7MB, the other two don't seem to be more than 4MB.
astor
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
