[Gcl-devel] Re: danger of open

[Camm Maguire]

Greetings!

Matt Kaufmann <address@hidden> writes:

> Hi --
> 
> Thank you for the quick reply!
> 
> I realize now that I can just handle this issue at the ACL2 level, by
> causing an error on an attempt to call open on a string starting with
> the | character.  (As a possibly humorous aside: I forgot to quote
> (open "|kill -9 -1") as a format argument in my error message, and
> sure enough, when testing an illegal open I managed to log myself out!
> Ouch.)
> 

OK.  Other options in case you find them useful are

1) runtime setting disabling piped opens
2) compile time setting doing the same
3) running the pipe in a sanitized subshell incapable of interfering
   with the parent. (my favorite)

> But here are some observations in case you find them helpful.
> 
> I guess it wouldn't help me to check the type of the returned stream,
> since I want to avoid executing code after the pipe.  Anyhow, for what
> it's worth, it looks like GCL 2.7.0 ANSI (a version Boyer sent me
> yesterday) returns FILE-STREAM for the type of a stream connected to
> other than a file.
> 
>   >(setq str (open "|cat tmp" :direction :input))
> 
>   #<input stream "|cat tmp">
> 
>   >(type-of str)
> 
>   FILE-STREAM
> 
>   >
> 
> But actually, the ANSI spec for open seems to require a FILE-STREAM
> (or nil) to be returned; see
> http://www.lisp.org/HyperSpec/Body/fun_open.html#open.  So I'm not
> sure that the above OPEN is legal.
> 

Well, if we must return a file-stream, we must.  I think a pipe fits
that concept, at least within the unix philosophy.  Perhaps an
additional predicate 'seekable-stream-p?  There are all sorts of
objects one might open that are not seekable.  In fact, I'm not sure
CL supports file repositioning more than one char at a time.
char devices (e.g. /dev/random), fifos, sockets, etc.

Take care,

> Thanks --
> -- Matt
>    Cc: address@hidden, address@hidden, address@hidden
>    From: Camm Maguire <address@hidden>
>    Date: 30 Oct 2006 14:54:44 -0500
>    X-SpamAssassin-Status: No, hits=-2.5 required=5.0
>    X-UTCS-Spam-Status: No, hits=-240 required=200
> 
>    Greetings!
> 
>    IMHO, this is a pretty useful feature of GCL, which helps in
>    auto-decompressing compressed files, outputting straight to a printer,
>    etc.  It also matches the unix convention of "pipes as file objects"
>    -- e.g. gnuplot and many other programs work this way.  
> 
>    Perhaps some predicate on the stream would help?  If memory serves,
>    the ansi standard has such notions, e.g. 'file-streams'.
> 
>    Take care,
> 
>    Matt Kaufmann <address@hidden> writes:
> 
>    > Hi, Camm --
>    > 
>    > Bob Boyer pointed out something scary to me back in May, and I'm
>    > finally getting around to asking you about it.  He noticed that by
>    > executing (open "|kill -9 -1") in GCL, you can logout and kill all
>    > your processes!  Or just start up GCL in Linux, suspend and use ps to
>    > get the process id -- say it's 23327 -- and then do this to kill your
>    > GCL:
>    > 
>    > (open "|kill -9 23327")
>    > 
>    > This is scary from an ACL2 perspective, when I'd expected that open
>    > just does an open.  I suppose we could look for a first character of
>    > #\| and cause an error in that case.  But maybe you want to consider
>    > eliminating this GCL feature?
>    > 
>    > Thanks --
>    > -- Matt
>    > 
>    > 
>    > 
> 
>    -- 
>    Camm Maguire                                               address@hidden
>    ==========================================================================
>    "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah