From: Mike Cox
Subject: Re: What c++, and most other languages don't have, but c# does
Date:
Message-ID: <30cfslF1dsrm2U1@uni-berlin.de>
John Bailo wrote:
>
> Reflection.
>
> The ability to take code at a meta level and have it refer to itself.
>
> For instance, right now I'm creating a dynamic enum for a web service.
>
> The enum compiles itself at runtime, so that the enum can be used in the
> subsequent code.
>
> It's /amazing/
>
Bailo, LISP can do that. And much more. Using Macros you can modify a
running program.
Mike Cox <············@yahoo.com> wrote in message news:<···············@uni-berlin.de>...
> John Bailo wrote:
>
> >
> > Reflection.
> >
> > The ability to take code at a meta level and have it refer to itself.
> >
> > For instance, right now I'm creating a dynamic enum for a web service.
> >
> > The enum compiles itself at runtime, so that the enum can be used in the
> > subsequent code.
> >
> > It's /amazing/
> >
>
> Bailo, LISP can do that. And much more. Using Macros you can modify a
> running program.
That is a misconception. Macros are simply user-defined hooks in the
compiler, which are written as Lisp functions. they are Lisp code that
has a chance to opeate on Lisp source code (as a data structure) and
transform it before it gets finally compiled or interpreted. Once the
code is ``baked'' through macros, it does not change.
Macros don't overwrite their inputs. They analyze the input code and
synthesize a data structure representing the transformed code.
A running Lisp image is self modifying in the sense that there are
certain deliberate ``flexible joints'' in the language that allow for
the content of that image to change. The evaluator and compiler are
available as functions, so it is possible to compile and load new code
into the image. New functions can replace old ones, but that is not
done by overwriting their code. Rather, the symbolic references are
updated to point to the new code, so that new calls to a function use
the new version. The old code continues to exist as long as there are
threads whose instruction pointer is running that code. Once nothing
is executing a piece of code, and no other type of reference exists to
it, it can be garbage collected.
You can look at that as sort of disciplined self-modification. The
same thing is done with other technologies, such as dynamically loaded
libraries (so called ``plugins'') loadable operating system drivers,
or the very idea of an operating system with processes that load, run,
terminate and unload. Your running OS as a whole is a self-modifying
system, only far more fragile and coarse-grained than a Lisp image.
You can start and stop programs, install and uninstall them, etc.
From: john bailo
Subject: Re: What c++, and most other languages don't have, but c# does
Date:
Message-ID: <30fbtnF2uo2gkU1@uni-berlin.de>
This is a multi-part message in MIME format.
--------------060900000304040602090303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Kaz Kylheku wrote:
> You can look at that as sort of disciplined self-modification. The
> same thing is done with other technologies, such as dynamically loaded
> libraries (so called ``plugins'') loadable operating system drivers,
> or the very idea of an operating system with processes that load, run,
> terminate and unload. Your running OS as a whole is a self-modifying
> system, only far more fragile and coarse-grained than a Lisp image.
> You can start and stop programs, install and uninstall them, etc.
Well for that matter, since almost all Linuxes have a gnu cc compiler
available to every user, I could just write a program, using syscalls,
that:
1. Opens a file
2. Writes a c++ program to the file.
3. executes the gcc compiler on the file
4. runs the newly compiled file
( Can I pass a source file into gcc and have the output execute all in
one line of shell script ? )
5. The newly compiled file could have instructions to make an image or
modified image of itself, or,
6. It could delete it's parent program file.
In fact, given that the gcc is on almost every Linux system, I'm
surprised that there are not more viruses in Unix systems that
constantly replicate themselves, changing their name at random.
--------------060900000304040602090303
Content-Type: text/x-vcard; charset=utf-8;
name="jabailo.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="jabailo.vcf"
begin:vcard
fn:John Bailo
n:Bailo;John
org:Texeme Construct;Memeology and Semantics
adr:;;;Kent East Hill;WA;98030;USA
······················@earthlink.net
title:Leader
url:http://texeme.com
version:2.1
end:vcard
--------------060900000304040602090303--
john bailo <·······@earthlink.net> wrote
> 2. Writes a c++ program to the file.
> 3. executes the gcc compiler on the file
<snip>
> In fact, given that the gcc is on almost every Linux system, I'm
> surprised that there are not more viruses in Unix systems that
> constantly replicate themselves, changing their name at random.
Maybe it's because it would be stoopid?
john bailo <·······@earthlink.net> writes:
> In fact, given that the gcc is on almost every Linux system, I'm
> surprised that there are not more viruses in Unix systems that
> constantly replicate themselves, changing their name at random.
mount -o noexec /home ;-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
From: David Steuber
Subject: Re: What c++, and most other languages don't have, but c# does
Date:
Message-ID: <87llcs4tml.fsf@david-steuber.com>
Pascal Bourguignon <····@mouse-potato.com> writes:
> john bailo <·······@earthlink.net> writes:
> > In fact, given that the gcc is on almost every Linux system, I'm
> > surprised that there are not more viruses in Unix systems that
> > constantly replicate themselves, changing their name at random.
>
> mount -o noexec /home ;-)
This prevents executing any files on the /home file system? Including
shell scripts and such?
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber <·····@david-steuber.com> writes:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
> > john bailo <·······@earthlink.net> writes:
> > > In fact, given that the gcc is on almost every Linux system, I'm
> > > surprised that there are not more viruses in Unix systems that
> > > constantly replicate themselves, changing their name at random.
> >
> > mount -o noexec /home ;-)
>
> This prevents executing any files on the /home file system? Including
> shell scripts and such?
Yes. Nifty isn't it.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
From: Svein Ove Aas
Subject: Re: What c++, and most other languages don't have, but c# does
Date:
Message-ID: <cnvvlk$3ra$1@services.kq.no>
Pascal Bourguignon wrote:
> David Steuber <·····@david-steuber.com> writes:
>
>> Pascal Bourguignon <····@mouse-potato.com> writes:
>>
>> > john bailo <·······@earthlink.net> writes:
>> > > In fact, given that the gcc is on almost every Linux system, I'm
>> > > surprised that there are not more viruses in Unix systems that
>> > > constantly replicate themselves, changing their name at random.
>> >
>> > mount -o noexec /home ;-)
>>
>> This prevents executing any files on the /home file system? Including
>> shell scripts and such?
>
> Yes. Nifty isn't it.
>
Annoying is the word.
I've used such systems in the past, but I'm a programmer; I *must* have my
customized tools. At one point it got bad enough that I exploited a
buffer-overflow in bc to turn it into a program loader.
The solution isn't to prevent execution of user programs; the solution is to
have them run in a different capability domain than system-provided
executables, by default. Give us some credit!
From: Neo-LISPer
Subject: Re: What c++, and most other languages don't have, but c# does
Date:
Message-ID: <220249188.OFKqBvok9y@yahoo.com>
john bailo wrote:
> Kaz Kylheku wrote:
>
>> You can look at that as sort of disciplined self-modification. The
>> same thing is done with other technologies, such as dynamically loaded
>> libraries (so called ``plugins'') loadable operating system drivers,
>> or the very idea of an operating system with processes that load, run,
>> terminate and unload. Your running OS as a whole is a self-modifying
>> system, only far more fragile and coarse-grained than a Lisp image.
>> You can start and stop programs, install and uninstall them, etc.
>
> Well for that matter, since almost all Linuxes have a gnu cc compiler
> available to every user, I could just write a program, using syscalls,
> that:
>
> 1. Opens a file
> 2. Writes a c++ program to the file.
> 3. executes the gcc compiler on the file
> 4. runs the newly compiled file
>
> ( Can I pass a source file into gcc and have the output execute all in
> one line of shell script ? )
Of course.
cat > foo.cpp && gcc -o foo foo.cpp && ./foo
> 5. The newly compiled file could have instructions to make an image or
> modified image of itself, or,
> 6. It could delete it's parent program file.
In a more sophisticated form, this type of argument mentions dlopen (or some
ELF loader). Remember, modifying a *running* program was discussed, not
overwriting binaries for future runs.
> In fact, given that the gcc is on almost every Linux system,
> I'm surprised that there are not more viruses in Unix systems
> that constantly replicate themselves, changing their name at random.
Because to spread from one system to another, a virus has to exploit either
some vulnerability of user incompetence.
From: Karl A. Krueger
Subject: Re: What c++, and most other languages don't have, but c# does
Date:
Message-ID: <cnudqn$7a5$1@baldur.whoi.edu>
In comp.lang.lisp john bailo <·······@earthlink.net> wrote:
> ( Can I pass a source file into gcc and have the output execute all in
> one line of shell script ? )
It would be amusing to be able to do:
echo "int main { printf('Moose\n'); }" | gcc -o - - | exec
... but it don't work that way.
(First off, gcc won't write binary to standard output; second, as far as
I know there's no "exec" command line program that accepts an executable
on standard input and runs it.)
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
Every program has at least one bug and can be shortened by at least one line.
By induction, every program can be reduced to one line which does not work.
Karl A. Krueger wrote:
> In comp.lang.lisp john bailo <·······@earthlink.net> wrote:
>> ( Can I pass a source file into gcc and have the output execute all in
>> one line of shell script ? )
>
> It would be amusing to be able to do:
>
> echo "int main { printf('Moose\n'); }" | gcc -o - - | exec
>
> ... but it don't work that way.
>
> (First off, gcc won't write binary to standard output; second, as far as
> I know there's no "exec" command line program that accepts an executable
> on standard input and runs it.)
>
couldn't you set the gcc output to an environmental variable and the pass
that to an exec ?
--
http://www.texeme.com
From: Marco Antoniotti
Subject: Re: What c++, and most other languages don't have, but c# does
Date:
Message-ID: <iVHod.26$E26.32903@typhoon.nyu.edu>
john bailo wrote:
> Kaz Kylheku wrote:
>
>> You can look at that as sort of disciplined self-modification. The
>> same thing is done with other technologies, such as dynamically loaded
>> libraries (so called ``plugins'') loadable operating system drivers,
>> or the very idea of an operating system with processes that load, run,
>> terminate and unload. Your running OS as a whole is a self-modifying
>> system, only far more fragile and coarse-grained than a Lisp image.
>> You can start and stop programs, install and uninstall them, etc.
>
>
> Well for that matter, since almost all Linuxes have a gnu cc compiler
> available to every user, I could just write a program, using syscalls,
> that:
>
> 1. Opens a file
> 2. Writes a c++ program to the file.
> 3. executes the gcc compiler on the file
> 4. runs the newly compiled file
>
> ( Can I pass a source file into gcc and have the output execute all in
> one line of shell script ? )
>
> 5. The newly compiled file could have instructions to make an image or
> modified image of itself, or,
> 6. It could delete it's parent program file.
Yep. But you cannot easily construct a set of functions at runtime,
stash them in a data structutre of sort (say a tree) and then compile a
subset and run them all on some data.
You could probably do some fancy shared lib programming to achieve that,
but why, when you can easily write assembly code? :)
Cheers
Marco
>
>
> In fact, given that the gcc is on almost every Linux system, I'm
> surprised that there are not more viruses in Unix systems that
> constantly replicate themselves, changing their name at random.
>
john bailo <·······@earthlink.net> writes:
> Kaz Kylheku wrote:
>
[how Lisp really works]
>
> Well for that matter, since almost all Linuxes have a gnu cc compiler
> available to every user, I could just write a program, using syscalls,
> that:
>
> 1. Opens a file
> 2. Writes a c++ program to the file.
> 3. executes the gcc compiler on the file
> 4. runs the newly compiled file
*If* you are into that sort of thing and you can live
without the plus-plus part, then I'd reccommend tcc
<http://fabrice.bellard.free.fr/tcc/>
> ( Can I pass a source file into gcc and have the output execute all in
> one line of shell script ? )
As another poster put it, the bigger problem (at least
on Unixids) seems to be executing the output of a pipeline.
But with temp files...
[...]
> In fact, given that the gcc is on almost every Linux system, I'm
> surprised that there are not more viruses in Unix systems that
> constantly replicate themselves, changing their name at random.
A long tradition not to run everything as root?
A virus (or worm, or whatever) is far less useful when running
as nobody, maybe even with enforced ulimits.
Maybe that changes when more and more end-users use Linux or
whatever. Don't know.
Regards
-- tom�s
From: Neo-LISPer
Subject: Re: What c++, and most other languages don't have, but c# does
Date:
Message-ID: <1599504.JfO0SkYRRd@yahoo.com>
·····@versatel.de wrote:
>
> If you are into that sort of thing and you can live
> without the plus-plus part, then I'd reccommend tcc
> <http://fabrice.bellard.free.fr/tcc/>
>
What makes tcc more suitable than gcc for this kind of misuse?
Quoth Neo-LISPer on or about 2004-11-23:
> > If you are into that sort of thing and you can live
> > without the plus-plus part, then I'd reccommend tcc
> > <http://fabrice.bellard.free.fr/tcc/>
>
> What makes tcc more suitable than gcc for this kind of misuse?
Bangpaths work.
#!/usr/bin/tcc -run
#include <stdio.h>
main() { printf ("foo!\n"); }
-t
From: ·····@nospam.versatel.de
Subject: Re: What c++, and most other languages don't have, but c# does
Date:
Message-ID: <87is7wqv7z.fsf@viamalissima.trapp.net>
Neo-LISPer <··········@yahoo.com> writes:
> ·····@versatel.de wrote:
[tcc]
> What makes tcc more suitable than gcc for this kind of misuse?
Size and compilation times (the low latency makes you believe
you're dealing with an interpreter).
Plus, it comes with some handy goodies you'd have to build
by hand yourself: e.g. libtcc: compile snippets of C code from
your app and execute them; or ``#!/usr/local/bin/tcc -run''.
You get the idea.
Gcc optimizes better, is more generic (you have more front-ends
and back-ends), but it's a behemoth.
(But we're getting off-topic already, I fear).
Regards
-- tom�s
·····@versatel.de wrote:
> *If* you are into that sort of thing and you can live
> without the plus-plus part, then I'd reccommend tcc
> <http://fabrice.bellard.free.fr/tcc/>
But the point is that gcc is on every Linux machine.
And hence an entry point for exploits.
> As another poster put it, the bigger problem (at least
> on Unixids) seems to be executing the output of a pipeline.
Well that was just a bonus.
The real strength of my virus design is that the program that replicates,
then activates the newly generated copy. Then the copy deletes the parent.
--
http://www.texeme.com
From: Karl A. Krueger
Subject: Re: What c++, and most other languages don't have, but c# does
Date:
Message-ID: <cnvvd8$md8$1@baldur.whoi.edu>
In comp.lang.lisp ·····@versatel.de wrote:
> john bailo <·······@earthlink.net> writes:
>> In fact, given that the gcc is on almost every Linux system, I'm
>> surprised that there are not more viruses in Unix systems that
>> constantly replicate themselves, changing their name at random.
>
> A long tradition not to run everything as root?
>
> A virus (or worm, or whatever) is far less useful when running
> as nobody, maybe even with enforced ulimits.
Well, actually, the "Slapper" worm which attacked Apache-SSL (via a
security hole in OpenSSL) did, as I recall, compile itself using gcc on
each system. So at least one Linux worm has, in fact, taken advantage
of the presence of a compiler on each system.
Moreover, Slapper did not need to run as root -- it ran as the "nobody"
or "www-data" user that Apache runs as. This user is perfectly capable
of making network connections to spread the worm, as well as to listen
on a socket to allow unauthorized access. Slapper stored its files in
/tmp, which is generally world-writable on Unix systems, and which is
required for a -lot- of applications.
One security measure that would defend against this would have been to
disallow executables in /tmp (and in other filesystems writable by the
Apache user). This is possible in Linux (and has been for some time) by
placing /tmp on a filesystem that is mounted noexec. However, this is
not usually done.
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
Every program has at least one bug and can be shortened by at least one line.
By induction, every program can be reduced to one line which does not work.